Steve Yegge's scathing criticism of agile methodologies takes a page from Joel Spolsky's book. It's not merely an indictment of Agile, it's also a celebration of how his company does business. Just substitute "Google" for "Fog Creek Software" and you'll get the idea.
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/10/anything-but-waterfall.html
Great post as usual. I think there is middle ground between BDUF and XP. That’s probably where most of us spend our time.
Having been doing this stuff for 20+ years, I’ve seen very good, hopeless, and in between.
- you need to think stuff through as best you can
- you need to use a language/tool that let’s you get things done relatively quickly (whatever that means)
- your building blocks need to be such that they can be modified and/or jiggled around relatively easily
- build a kick-ass library of re-useable functions and make people use them
- code review, and mentor
- estimate carefully, work on fixed price, and when the customer has a change say “no problem, but it’s time and money”
- prototype with the user at regular intervals
This stuff stays pretty much the same year after year. Tools get better (and sometimes worse). Programmers many times write code without thinking very much beforehand (and may call that XP). Event driven programming made things more complex in some ways.
I don’t think I really believe all of this Google story. At some point something has a priority, some boundaries (so you know when it’s done), etc., and enough people working on it so as to not need more developers one week than make sense.
For the anti-Waterfall movement to catch on, it needs a catchy name.
I was really surprised that there wasn’t a YouTube link to TLC’s “don’t go chasing waterfalls”…
The comparison to religion is an apt one. Google’s development philosophy seems to boil down to “hire a bunch of really smart people, treat them well, and have faith that they’ll come up with cool stuff”.
In Google’s case, it probably mostly works because they really only have one product - an ad firehose. All of their other “products” have as their only goal to widen the stream. The cost of failure (and they’ve had them) is low, and even modest success is purely accretive.
Hardly your typical development organization.
The truth is often somewhere in the middle. There’s no silver bullet for the problems of software development. You’ll get far by planning ahead, by communicating a lot (more), by not reinventing what someone else has already invented, and so on. Look at other mature engineering disciplines and learn from them; software development really isn’t that unique.
Like Kevin says, what works at Google won’t necessarily work elsewhere. In many ways, Google creates its own weather patterns.
I’m all for no artificial deadlines (http://haacked.com/archive/2006/03/12/ArtificialDeadlinesAreTheDevilsWork.aspx) but no deadlines would seem to run afour of Parkinson’s Law (http://en.wikipedia.org/wiki/Parkinson’s_law).
I’d be all for no-deadlines honestly, but I have this little problem of clients and their whiny demands. Something Google doesn’t have to worry about apparently.
But you gotta admit, part of you would like to work in that developer’s Utopia, if it were found to be true.
There was an email discussion of this at work in response to us using Scrum, one of the “Evil Agiles.” Here was my response, with comparisons to scrum [in brackets]. Sorry for the length, it’s mostly due to copy-and-paste of Stevey’s stuff.
I find that the Waterfall method would be a step up from the way most shops (that I’ve seen) are run.
You folks need to get state of the art. If you’d been to Waterfall 2006 you’d be singing a different tune. The developments are profound and inspiring.
Are you sure that you really like to go down the “Guilt by Association” road?
Google employees work in a building.
Enron employees worked in a building.
Enron was evil.
Methodologies are just like religions. They don’t apply to everyone and each has some factor of error in logic/implementation.
Holistically you cannot box your product into any given pre-existing process. The process must enable the product, it’s not the other way around. This is why most methodologies fail.
It’s like picking up a wrench, and finding out you need to drive in a nail. You can use the wrench to bang on the nail head, but at the end of the day you exhausted your effort using the wrong process to complete the product. If you had examined the product you would have known that a hammer would be much more useful. The problem is knowing up front that you are building a garage and not changing a tire. CLEAR Objectification of your product and determination of scope up front… I don’t know what methodologies support that, I have been privy to a few, but maybe the “priest” was more interested in the end result than managing the congregation.
The Enron-Google comparison is actually much more than just guilt by association. Having read “The Smartest Guys in the Room” just before reading Yegge’s blog rant, I was struck by a number of similarities.
Enron’s problem was actually NOT that it was evil. Enron was simply unprofitable. Or rather, it had only one profitable business (trading) which supported all its other businesses, most of which were huge money sinks. They spent much of their time desperately searching for the “next big thing”, but never had the patience to allow any of these initiatives time to grow into real businesses. Finally, when their one profitable business hit a rough patch, the company imploded.
All the accounting scandals and so on which prompted the creation of SOX merely delayed the inevitable. SOX would not have prevented Enron’s implosion, it would only have made it happen sooner and with less collateral damage.
Anyway, the parallels with Google should be clear. Google is mostly supported by its search business, which is massively profitable, but it remains mostly a one-trick pony. None of its other businesses come close to replicating their success in search, in fact many of them are total busts. Much of the cultural stuff described by Yegge looks very much like a desperate hunt for the “next big thing” - but just like Enron, Google appears to lack the stamina to see any of them through.
Fortunately for Google, it looks highly unlikely that their search product will implode in the same way as Enron’s trading did. After all, trading is intrinsically volatile. But if a big competitor (eg Yahoo or MS) managed to eat enough of their market in search, I think they would quickly have to switch to a much more conventional (ie profit-driven) way of doing business.
Hmm. nice post good links. Trouble is, Im wondering whether I ought to ask my tutor that I dont want to use UP in my software model and please may I use agile instead? I wonder what he would say. I suppose you need to know the rules before you can break them …
I agree to Neil mostly. Google loves off its search, and essentially has a kilo of other little services that should just cover costs and create public attention. A person that uses a google image viewer, a google mini search and other junk is IMHO unlikely to not use Google for searching, too!
IMHO, a service is a winner for google if it covers its development costs…
Nice post as usual, but how do you push your company to change their methods, I mean I could do it, but the top level managements, project managers, and a bunch of other people who just cant life without BDUF?
Should I tell them to read codinghorror.com?
Having one big source of review is the way most big companies work, it’s specialization. One company builds cars, another owns houses in Manhattan. I don’t see Google being much more vulnerable than any other company in this aspect. The whole “I’m not aware of any pending motto enforcement acts.” sounds very much like, “there is just a matter of time until they do something evil” to me and whole thing sounds very much like an attempt to use a company which had a very bad name to smear another. Why choose Enron? There are plenty of companies with a similar strategy.
I liked Steve’s article but only because I had my own ideas about Agile and they tend to err on the side of Steve’s. Also, I liked hearing about Google.
As for Agile… there’s not a lot I like about it. Note cards up in your cube? Why not use gasp a real bug tracking/task managing system. Daily meetings? Gag. Pair programming? Put me in a dark room, give me my tasks and leave me alone and I’ll have them done quicker than if I have to sit in a cramped cube with someone else and watch them code.
Yes, Waterfall sucks but Agile also sucks. There are other ways to do it besides Waterfall and Agile too.
And for those that think that Google is evil… honestly, if they do what Steve said they did, I want to freaking work there. That sounds a lot better than all the companies I’ve worked for.
“There aren’t Gantt charts…”
Gantt charts are evil. Every project I’ve worked on that had a “project manager” or used Gantt charts was a massive failure.