Good Agile — Development Without Deadlines 339
BigTom writes, "In a recent blog entry Steve Yegge, a developer at Google, writes a fascinating account of life at possibly the coolest development organization in the world. Steve lays out
some of the software development practices that make Google work. Go on, say you are not even a little bit jealous. ;-)" From the article:
- Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
- There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.
- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
- Google tends not to pre-announce. They really do understand that you can't rush good cooking, you can't rush babies out, and you can't rush software development.
3 meetings a week! (Score:5, Insightful)
Where I work, we have an average of about 1. and sonme of us think that that's too many
Re:3 meetings a week! (Score:4, Insightful)
In most places I've worked it's been no more than once per two weeks for the prorgrammers. The buisiness side of things has more, but hey, that's what business people are payed for, to sit around and talk while others do the work.
Ok, the business side fo things does do work, but the programmers shouldn't have to go to meetings like that. Their meetings are more like the occasional team huddle to verify that they are working on the right path - 5 minutes, quick, and to the point
Re: (Score:2)
Re:3 meetings a week! (Score:4, Interesting)
I can teleconference in and get real work done at the same time.
I've been on those sorts of teleconferences. I think the key is to mute your speaker phone and listen only for your name in the conversation - you'll get tons of real work done that way.
Re: (Score:3, Insightful)
This is typical of software guys. You do know that someone pays your checks right? The guys paying your wages are the ones sitting in meeting trying to figure out a few things:
Re: (Score:3, Insightful)
Switching teams? Right, and that makes agile development work. Sure. Of course, I have found out that what agile deveolpment REALLY does is push MORE work onto your DBA and tech support teams, in order to "reduce" the work of the development
Re:3 meetings a week! (Score:4, Funny)
I think it explains why much of Google's stuff is currently in beta.
Re: (Score:3, Insightful)
Re:3 meetings a week! (Score:5, Insightful)
Considering how often Google puts up new features on their site, apparently it works pretty good for them.
Regarding the number of meetings, I only have one formal meeting a week, but can spend several hours a week with a couple other guys talking over the specifics of whatever we're working on. Could be considered "meetings", even though they don't involve sitting around a table and going through an agenda.
Re: (Score:2)
> other guys talking over the specifics of whatever we're working on. Could be considered "meetings", even though they don't
> involve sitting around a table and going through an agenda.
right, so it isn't a meeting if you're not sitting down.
so, the best way to reduce meetings is to stand up when having "work-oriented get-togethers"? Sounds so simple, I wish we had figured that
Re:3 meetings a week! (Score:5, Insightful)
This is a direct by product of the type of person that google hires. They look for the really smart self motivated type. This is the same type of person that writes OSS (and no one tells them what to work on and there are surprisingly quite a few OSS projects in various stages of completion). Your comment also ignores the fact that no projects are ever really finished.
Googles method is a good one, and it works for them. I do think the author missed one of the huge reasons that it works - googles hiring practices.
Re: (Score:3, Insightful)
That said, I agree that it's all about its hiring practices. The talented and self-motivated person is a rare and special thing to find and hire. The Google Agile practices would never work at any company I've ever worked at because most of the engineers (yes, most) at those companies would end up day-trading, playing Quake, or gambling online (or even, *gasp*, posting re
Re: (Score:3, Interesting)
Exactly. To take a sports example, look at the West Coast offense in American football. Sure it worked great for San Francisco in the 80's. They had Montana, Rice, Craig, and a stout offensive line. Just about any offensive scheme would've worked for them. For the Lions, West Coast Offense never did work out quite right when the Mooch went there. They utterly lack the personnel. Google is picking up the personnel who will thrive in th
Re: (Score:3, Funny)
Is there an administrator in the house?
Re: (Score:3, Interesting)
No more wrong than the Atlanta Falcons spending years in the NFC West while the Arizona Cardinals were in the NFC East. Terminology gets butchered quite often in the NFL. It seems like you would be used to it by now.
The offense that Don Coryell used was referred to as "Air Coryell." The term West Coast Offense didn't come until much later. It was a term originally intended to refer to the Coryell offense but due t
Re: (Score:2)
Re: (Score:2)
Come to think of it, that describes most retail software.
At least Google's honest about it.
Re: (Score:3, Insightful)
That is my point. We are trying out agile development here, and because of it, the developers are causing the DBA group to do multiples of the work they used to do. So far only one test project, but it is enough to see what i
Re:3 meetings a week! (Score:5, Insightful)
Re: (Score:3, Insightful)
Re: (Score:2)
Where can I send my resume? Just reviewing the past few days shows no fewer than 6 meetings since Monday for projects that are all related to each other. I also have weekly team meetings and daily systems stability meetings. It has gotten to the point that I have to reserve slots on my calendar to get work done. To be fair, though, I am an architect now and no longer strictly a developer, so I am forced to have a lit
Re: (Score:2)
Re: (Score:2)
Re:3 meetings a week! (Score:4, Insightful)
One is just a weekly status update with your team lead, which seems fine.
The other two, I'd wager, are probably pretty short, unstructured coordination sessions. Making sure everyone's on the right page, person to person. Also, perfectly fine.
Meetings aren't necessarily a bad thing; it's the completely worthless, unproductive types that you need to watch out for.
You'd hate my team (Score:2)
Must be nice in Candyland (Score:5, Interesting)
That said, it's a very interesting example to consider. Within the coming months I'll be forming a new application development group, and the mechanisms of determining what we'll be working on and how it will be prioritized are TBD. Good food for thought, here...
Sure, The Policy Is Dazzlingly Brilliant *NOW* (Score:3, Funny)
Check back in five years, there's some kind of upheaval in Middle-Central-Lower Slobovia, the Market tanks, Sergey's enmeshed in a sex scandal with an Israeli weight-lifter, shareholders revolt,
Re:Sure, The Policy Is Dazzlingly Brilliant *NOW* (Score:5, Insightful)
Google's making money. Actual real profits. You must be thinking of YouTube or something.
During the 90's, the companies that were being touted as being run by genius management were pretty much not doing anything but helping the manufacturers of $800 office chairs get rich.
Re:Sure, The Policy Is Dazzlingly Brilliant *NOW* (Score:5, Insightful)
That's one sign they have a clue what they're doing.
Re: (Score:2, Funny)
Re: (Score:2)
Those $800 office chairs are worth every penny [joelonsoftware.com]. Everyone at my company [adknowledge.com] has one (unless they prefer something else) and I'll never again work for a company that does not provide them. When you're spending 8+ hours a day sitting in a chair, you need a good one.
Some of Google is making money (Score:3, Insightful)
Google's main business is surely very profitable, but how many of the little, random-idea things are making money for them? How many of their services don't carry that all-important advertising? What's underwriting the various accumulation/caching/republishing services to fight off the inevitable lawsuits when they step too far over the line? The biggest difference between a lot of Google's offerings and a lot of failing start-ups is that Google has
Re: (Score:3, Insightful)
This isn't anything to do with revolutionary management or development tactics, but good old fashioned advertising principles.
Excuse me if I don't join the worshipping of what at the end of the day is just a giant marketing corporation that makes a few novel permanently-beta web applications on the side.
Re: (Score:2)
Also, all that profit comes from the two core inventions (which were genuinely superb) that launched the company. For all the slobbering over Google development (OMG, a blog!), they've done exactly what in the last five years that's significantly better than their competitors? GMail is the only thing that comes to mind, and that's not exactly earthshaking either.
Re: (Score:2, Funny)
According to Google ads, there are thousands of local women who want to meet me NOW! That is significantly better than anyone else has ever done for me in the past.
Re: (Score:3, Insightful)
Google gave us a better search engine and some derivative web 2.0 apps.
Re: (Score:2)
besides search/adds? (Score:5, Interesting)
As you mentioned, with their huge amount of capital, they can afford highly in-efficient project management. I pity the fool who tries to introduce this management style into a smaller organization with budgetary concerns and uncontrollable deadlines. Not that I wouldn't mind working in their environment one bit. Either as a coder, or as a PM.
-Rick
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Now pull your head out of the toilet of fanboyism and try to imagine applying non-proffitable project management to a company that doesn't have huge sums of money to loose while looking for another cash cow. The vast majority of developers work in businesses that are not IT companies. Companies where there are deadlines, budgets, time constraints, and customers.
As I said, I would love to experience the Google workstyle, but it is only applicable in places lik
Re: (Score:3, Insightful)
I also agree, that free of leashes we can do some brutally awesome things. But in the majority of corporate worlds, that just isn't an option. As much as I'd love to create a custom leasing solution designed to directly mimic the exceptionally complex business needs of my organization, they can not afford the mu
Re: (Score:2)
In my experience this is somewhat exaggerated, but the tendency is there and it leads people to wait for management to make decisions instead of starting things on their own. Big problem if your management is incapable
Now we know why all the software is Beta (Score:4, Funny)
Re: (Score:2, Interesting)
Actually it makes me think of the ask.com commercials. Google doesn't have the tools because the developers aren't as motivated to act quickly?
Still, I use google over ask - all the tools in the world aren't useful if you don't have the right materials to use them on (in this case - a search engine that actually provides relevant, or at least, semi relevant results).
Re: (Score:2, Interesting)
Re: (Score:2)
Re:Now we know why all the software is Beta (Score:4, Interesting)
Re:Now we know why all the software is Beta (Score:5, Insightful)
Sweet! (Score:2)
Seriously, we cannot afford to be so cavalier about delivery dates etc in a team of four. In general, when the margin on the product isn't that great and/or you're understaffed, you'll run into trouble if you spend three days polishing how that button works.
So, how do you create great software when the resources are limited?
Re: (Score:2)
You do it yourself. Making all the decisions yourself.
Re: (Score:3, Interesting)
Not true (Score:5, Interesting)
I work for Google and I can tell you right now that is total horse shit. Google are not so different than my previous employers, Oracle and Microsoft.
If anything, working in Google is worse than Oracle/Microsoft due to the people I work with (brainwashed losers.) They are the type of people who want to join a cult.
Re:Not true (Score:5, Insightful)
I worked for Microsoft myself and I'm at Google now. There's a whole lot of brainwashing going on here at the miracle company. Yes, the benefits package is pretty good, and yes the work per se is pretty cool. But all the marketing hype that makes working here sound like working in heaven is so much inflated. Coincidentally enough, I'm planning on going to Oracle in the coming months -- there are a couple cool positions open in the group where a friend of mine works. Don't get me wrong, Google is cool, but nowhere near as cool as it's portrayed, especially here on Slashdot.
Sure, can I take your place! (Score:3, Funny)
Agile has a place too (Score:5, Insightful)
Google can do this, and pretty much any company that can set its own time-table can use "Google Agile" methods. But you're limited to just those products where a delay of a few weeks or months isn't a major issue. It's simply not true for every type of software developer out there.
Maybe "Agile" methods aren't the absolute best out there, but there are cases where it's simply not possible to use "Google Agile" methods.
Okay, sure (Score:5, Insightful)
Sure, that sounds wonderful, as long as:
- you're working with intelligent, competent, creative people
- you have an effectively unlimited budget(relative to most other companies)
- you're working for a software-only company which is only successful because of its innovation, not because it has to deliver specific functionality to specific clients
How many of us can say that? Hmm?
It sounds like a dream job, but let's face it: it relies on individual heroics, from everyone, all the time. Now that's fine if everyone working there is far above average, and "individual heroics" means "enough intelligence and maturity to keep a view of the big picture without being whipped with a rolled-up Gantt chart", but it's a recipe for disaster in most other places.
Is this the emerging ivory tower of Google developers? While I'm happy for the guy, most of the blog sounds like "look at me, I'm developing under near-ideal conditions, why isn't everyone else?"
Google tends not to pre-announce (Score:4, Insightful)
Yegge (Score:2)
Sounds like he still has a pretty one-dimensional view actually. Yegge often has interesting things to say, I just wish he didn't constantly have to be so bloody arrogant and condenscending about it, for instance:
anything that calls itself a "Methodology" is stupid, on general principle. [...]
And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people.
There are some really good refutat
Test (Score:3, Insightful)
Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
Having developers on a merry-go-round between projects is probably a good reason why their products never make it past the Beta stage (which is terrible).
There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.
One meeting a week should be sufficient. Three meetings a week spells inefficiency and poor process.
there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.
Okay, so now we're advocating against the use of project management techniques? Let's piss in the wind and hope it lands where we intended?
even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to.
There is tasty food everywhere in this world. Why does it need to be constantly emphasized that Google has tasty food? Google is a software company, not a restaurant. And secondly, the author makes it seem that in crunch periods, companies other than Google do not allow their employees to have lunch and dinner. I somehow suspect (legally, personally, ethically, etc.) that is not the case. Are the employees of EA starving during their crunch periods? :)
The point here is that Agile Development is a good model if its used properly. Using Google as an example to demonstrate how Agile is good, however, is a mistake. Subscribing to Google's use of Agile is a recipe for disaster.
Re: (Score:2)
Re: (Score:2)
I don't think it's a merry-go-round, it's getting people to go where they're interested and motivated. Look at FOSS; they're purely volunteers, but many stick with projects for years.
I'm currently working on a project that is OK, but I think there are other projects I could work on that would be more useful and involve code I know better. I suspect that
Re:Test (Score:4, Funny)
Considering they don't get paid, probably.
Re: (Score:2, Insightful)
I'm not quite sure which side I'm on in this, but the particular things you pointed out might be more relevant than you think. I'm currently enslaved to a Wall Street firm (That shall remain nameless), so let me give you some contrast...
Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
Here, and I suspect in most companies with large IT departments, we have a l
Re: (Score:2)
Re: (Score:2)
But everyone "wants" to work insane hours, right? (Score:2)
I can't say for certain since I don't work there, but I supect that everyone is expected to "want to" work insane hours. Just like how NCAA athletes aren't "required" to come to "voluntary" workouts -- only if they actually want playing time! I know folks who interviewed at Google and decided not to accept the job because i
Re: (Score:2)
Why?
I think you are confusing meetings with bad meetings. Sometimes you need multiple meetings a week so everyone can stay informed and on top of things. For example, I was placed in charge of an important module in a large software project and I would show up to the test meetings to see what the test status was, talk to the testers involved and discuss the test cases that were going to be run that day
The PHB response? (Score:5, Insightful)
But the PHBs will cherry-pick those aspects of Google's business that suits their preconceived comforts. Remember when we were all supposed to be like the Japanese? Show up for work, sing the company song, use just in time, statistical process control and all the other stuff? Yea, we were just like the Japanese, except for that pesky lifetime employment understanding. We'll just leave that one out - it really isn't important.
Don't criticise (Score:5, Insightful)
- Google is a company whose success is almost entirely based on innovation
- Innovation comes from intelligent, well-motivated people
- The best way to motivate intelligent people to innovate is to give them total freedom (rewards are just to give them a direction, NOT to motivate them - they are motivated because they love what they do. Try offering rewards for something they don't want to do, and see what happens...)
- Most companies (even software companies) make the majority of their money through churning out the goods, not innovating - Most companies do not have the funds or the original culture to even contemplate the above working practices
- It would be lovely to work for Google.
Personally I'm really glad this article got posted - it's not telling everyone how everyone should work, but it does offer insight into how Google works, and that's valuable insight indeed as long as it's not taken out of context.
Just keeping the talent happy... (Score:5, Insightful)
Google develops a large amount of its content in house in much the same way old movie studios developed all their films in house. For Google, the talent is not actors and directors but developers. Movie studios learned that you treat the talent well to keep them around and Google has taken that lesson to heart. Developers tend to want complete freedom to work on what they want with no deadlines and giving them this is the easiest way to keep them happy. Call it 'good agile development' or whatever else you want, it's really just keeping the talent happy in the hopes that they'll keep developing content to attract users.
Unfortunately, software companies that rely on software or service sales for revenue cannot take this extreme approach to agile development. They need to deliver software on occasion or someone else will replace them in the marketplace. Agile development is still the best way to go, but unbounded development only works if software isn't your primary source of revenue.
-Chris
Re: (Score:2)
Re: (Score:2, Funny)
Re: (Score:3, Interesting)
They actually have so much cash in outside investments that the SEC is considering regulating them as a mutual fund.
same conclusions (Score:4, Insightful)
Of-course not everyone can afford the same culture as Google, simply because not everyone has access to the same funds.
daily prayers (Score:2)
But I am an atheist and don't believe in prayers.
(and sorry for the spelling errors from the previous post, I don't really have that many incentives to be immensely grammatical here
the strategy... (Score:3, Insightful)
It's clear, good people in good mood, that's the best way to give incentives to your peers. second...
that is, killing the pressure in a smart way, and third....
that is, the respect of your peers is a KEY here, as a consequence that keeps things calm....
3 meetings a week? (Score:4, Insightful)
Google's getting too big.
Tell me about it! (Score:2)
The last job I quit was meetings-happy. They were a small engineering shop, maybe a dozen people. And they all manufactured and programmed a very simple line of widgets. Maybe a dozen models, two cpus. One of them was a 8051 just to let you know how simple these widgets are. There were 3 code bases common to the widgets. Really - no big deal.
So...how do you keep that many people busy on such simple crap? Filler Meetings.
We would have daily meetings. And progress meetings. And status meetings!
Reward vs. Entitlement (Score:5, Insightful)
What is interesting, however, is the way similar "perks" are perceived as rewards at Google. If you feel that perks are rightfully yours and must not be sacrificed even in the face of company financial difficulties (feeling "entitled"), then it's hard to make your brain justify working hard for your keep (or harder during particularly difficult times). Whereas if you are working on something for which you have genuine motivations AND have rewards to aim for, then the management has two aces in their deck: An employee's internal motivation (which can be invaluable), and external positive reinforcements. These two characteristics contribute directly to the health of the company both in its balance sheets and in its corporate culture, and that is A Good Thing.
Looking back, it wasn't the exuberance of the Bubble that destroyed it, because the way Google works can seem to be quite exuberant to some code monkey at Chrysler. It was the way that management could not decide (a) how to set business goals, and (b) how to manage its employees. When management forgets how to manage and employees forget how to work, you have a problem on your hands (see the sad saga that was Daikatana).
My company is better (Score:5, Funny)
We're not making any money yet, but it's only a matter of time! (Fingers crossed!)
Dates (Score:2)
Of course, you can forestall this kind of issue by smell
Don't really believe this part... (Score:2)
Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
Speaking as someone who has known a few Google employees, I don't believe this at all. Certainly Google is more accomodating than traditional firms, but I knew someone unhappy about his assignment who had to wait for quite a while (at least several months, not sure the exact length) before he could get it changed. I
It's must be all about HR (Score:5, Insightful)
Re:It must be all about HR (Score:3, Insightful)
you can't rush good cooking (Score:3, Insightful)
Many dishes are best when done quickly and often at high heat. Think of fajitas, calamari, tuna steaks, shrimp, stir-fry, and the list goes on. Likewise, leave your steak, burgers, chicken, veggies on the grill for 3 hours (hey, you can't rush good cooking right?) and you'll have charcoal.
There is a balance in all things. Cooking and software are no exceptions.
Google has a great setup for the business they're in. The company I'm at doesn't have the luxury of doing whatever we please. Our customers depend on us to deliver certain things on time. We like to think that we do have a core group who get to work on some "fun stuff" that doesn't have a fixed timeline (though we like to at least know what year we might get it out). I think Google can do things they way they are due to a LOT of cash on hand combined with the fact that they're really trying to find cool ways to attract people to their ads and attract ad buyers to their cool products.
Re: (Score:2)
Many dishes are best when done quickly and often at high heat. Think of fajitas, calamari, tuna steaks, shrimp, stir-fry,
But to stretch the analogy to breaking point: those kinds of dish rely on careful preparation. If you're making a chicken stir fry, you don't want to brown the meat, then find you've not chopped your onion yet.
One could, of course, take this as a metaphor for traditional software engineering methodology. Producing the High Leve
Re:you can't rush good cooking (Score:5, Insightful)
Yous till can't rush a stirfry
Its not rushed if its done in the right amount of time, even if that amount of time is short relative to other foods.
Herding cats (Score:5, Insightful)
My observation has been, if you are trying to herd cats you are using the wrong management technique.
You herd cattle, not cats.
With cats you put them in the general area of mice and let them do what they are good at. Cattle you herd to the slaughter house.
Most software projects fail due to poor management, then managers don't understand it is not an industrial activity. Most are still managing from that perspective. Software is more like R&D and in reading the description of Google it sounds like they have built a good R&D environment.
I havent't tried XP, but if it gets us away from the rigid factory model of development, more power to it.
OK, so the rules aren't too explicit (Score:3, Interesting)
Consider the government as an extreme counter-example.
The word TFA fails to use: leadership.
Someone who knew something of the subject, http://en.wikipedia.org/wiki/James_Stockdale [wikipedia.org] described five roles for a leader:
- moralist
- jurist
- philosopher
- steward
- teacher
Note the lack of "programs, process, policy, procedure, and paperwork" in the list.While Google may let people shift teams at will, I would be unsurprised to discover that shifts are infrequent.
Furthermore, by the time people start to abuse the culture, I would be unsurprised to discover that the culture ushes them to the door.
Have any of the major headz they've hired actually departed the big G?
first assume a spherical cow of uniform density... (Score:2)
now, simplify your process:
- "portfolio management" (ie, determining which projects move forward and which get cancelled) can be self-managing through the developers own self-interests
- developer productivity is handled through developer self-interest
- project scheduling is handled through developer self-interest
man, there's all kinds
News Flash: Egotist threatened by teamwork (Score:4, Insightful)
Even the much maligned (indirectly) Kent Beck went back and wrote version 2 and relaxed from the strict rosary of the 4 values and the 12 practices to a more organic view of values (still all required, up to 5 with "Respect" added) and practices (try 'em, but use what you need). The spirit of Agile is more about "Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.". Keep in mind, that phrase gets pulled like a gun when somebody tries to build up big seminars. I'm not saying people aren't making money off the Agile name, but it's flat out wrong to think it's a snake-oil sales system. Anyone with an Agile community around them can get in touch and talk face to face with practicioners (we're a friendly buch, honest;). All it will cost is the time, the gas, and perhaps a cup of coffee.
Google may be small 'a' agile, but it seems it can only afford to do so because it has a cash cow and technologists at the helm. The grad school/hippy commune the author describes can't exist in the smog of capitalism unless it can be hidden away somwhere because some moron with a bigger paychack is always saying "at the end of the day, we gotta do somethin'". In the rest of the corporate world Agile tools and practices not only gives the dev team a chance of "doin' somethin'".
Response from a developer at an agile shop (Score:3, Insightful)
Why doesn't the blog author just say, "Google has found the optimal development strategy for their market niche and guess what it is? Flexibility and profit sharing for the employees!" Big suprise. There was absolutely no good reason for him to wail on his straw man impression of agile. I work for a proud agile java development shop, Asynchrony Solutions, in St. Louis. Agile works amazingly well for our market niche where we are held financially accountable to produce deliverables for our customers. The "agileness" just keeps all the developers and the customers on the same page throughout the entire software development cycle.
This blog author conveniently chose to not mention many of the most rewarding concepts in agile development. Our agile process includes daily stand-up meetings. Around 10 am when just about everyone is accounted for, each team member standing in a circle takes a turn summarizing what they accomplished yesterday, and what they plan to accomplish today. This serves two major purposes: people must articulate their goals thus clarifying the big picture for everybody, and each person is held accountable by their peers for how their time is spent. You wouldn't believe how this motivates people to make themselves useful so that they don't have to explain why they have nothing to say to the group at the standup.
Shame on this blog author for not even going into how agile development works hand in hand with test-driven development. Well written unit tests coded at the same time as the software itself in atomic increments is the most amazing paradigm shift in software development for decades. I feel liberated when I can fearlessly refactor code that has been written months ago by different people and integrated everywhere in the project because they have properly maintained a test suite. Contrast this with a project that has no unit tests. You have to tip-toe around every line of code, and as the project grows, it becomes exponentially harder to make even the simplest refactor. Peer programming and the agile discipline enforce test-driven development in the real world.
This article made me sad because a lot of damage was done. The blog author is riding on the implied credibility from his position at google, but he is not a professional agile developer. Although the author was right to be upset about shameless vendors who don't care if what they are selling is a mismatch for their customers, I am in awe of how everyone at my company rallies around the agile flag because we are proud that we've got a development process that works for us and our clients, and the discipline to deliver great software. It may not be as visible or high profile as google, but I work with a staff that is just as driven and talented. I hope we don't miss out on any future business because of misconceptions born from this slanderous blog article.
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3, Interesting)
It sounds more like "have as many / few meetings as it takes to do the job."
At different points in a project, you need more meetings than at other points (and different types of meetings).
And yes, I'm jealous, darnit! I've been in places where there is a meeting every day, and nothing gets done (except preparing for meetings), and where there are NO meetings every week, and nothing (at least nothing on target) gets done. Both suck.
Re: (Score:3, Insightful)
Re: (Score:3, Funny)
Re: (Score:2, Insightful)
Re:No Wonder... (Score:5, Insightful)
In reality most software is either continously developed or it dies. I've worked on numerous software projects and few if any have ever reached a point where no more work was required. Even if you found and fixed every bug (haha), feature requests will continue to come in as people use the software. As soon as bugs/feature request quit coming in most software is essientially dead b/c that means people have quit using it.