Steve Yegge has a provocative blog about Agile methodologies. It’s vintage Steve: fun to read, cutting, opinionated; and, in many ways, largely right, I think. A couple of quick reactions:
The one component of “agile programming” that’s very much part of Google’s culture is unit testing, and that’s always seemed to me to be the most valuable part of agile/XP. When I was at the Googleplex in August, they even had exhortations about unit testing posted in the mens’ rooms. That’s certainly a deep part of the Google culture.
One of the follow-ups pointed out that the nature of Google’s business means that there isn’t the sort of time pressure you have when a customer is screaming for a new feature that he wants last month. That’s certainly true, BUT: At the same time, I’m seeing more and more companies have businesses that are built along Google’s model. Certainly every interesting start-up that I know of. (That begs the question of the uninteresting start-ups.) The perpetual beta does as much to eliminate the pressure for “FCS” as it does to encourage creativity. The perpetual beta, first formulated as “release early, release often,” is one reason behind the success of many open source projects over the years.
In defense of Agile methods, Google’s development methodology works largely because Google only hires very smart people. Don’t ask me how they found that many smart people, even in Silicon Valley. I’ve lived there, and I know that the density of smart people isn’t that much greater than it is anywhere else in the world. Anyway, one of my observations about business in the non-Google world is that a huge amount of it is getting people who really aren’t very bright surrounded by a process that somehow enables these people to turn the cranks and come out with something good at the other end. (I say that with all due respect to my readers, who I assume are the “bright” people at the top of this food chain.) Security audits, code reviews, waterfall, and even Agile: it’s really all the same game. And the “good” that you get from the end of the process is for a fairly tolerant value of “good”. More like “it doesn’t suck too bad”. But that’s the way most companies work. It’s a fair question: how broadly applicable is a methodology that assumes that you can hire people as smart as Google’s staff? Most companies can’t.
Yes, I know that Google engineers don’t walk on water. The deeper question is: with the sort of incentives that Steve describes at Google, could the average performer be motivated to do good work without the process? Or is the existence of the process itself important?