Home > Programming, Software Design > So Agile it Kind of Hurts

So Agile it Kind of Hurts

September 28th, 2006

What a roller coaster ride it was to read Steve Yegge’s post Good Agile, Bad Agile. For the first, say, third of the post I was enthralled because I agree wholeheartedly with Steve’s humorous critique of basically any software development methodology,

The rest of us have all known that Agile Methodologies are stupid, by application of any of the following well-known laws of marketing:- anything that calls itself a “Methodology” is stupid, on general principle.
– anything that requires “evangelists” and offers seminars, exists soley for the purpose of making money.
– anything that never mentions any competition or alternatives is dubiously self-serving.
– anything that does diagrams with hand-wavy math is stupid, on general principle.

And by “stupid”, I mean it’s “incredibly brilliant marketing targeted at stupid people.”

I personally think that all things Agile are succeeding (in terms of popularity) because while it’s very reasonable for me to say, “I don’t want to be eXtreme,” I’d feel pretty lame saying, “I don’t want to be agile.” The take away here is to always use a word with positive connotations for your thing. That way no one can say it’s bad without having to clarify themselves. I guess it was at some point categorically positive to be extreme (maybe), but “agile” has a more practical timelessness to its natural appeal.

Imagine my surprise, then, when I found myself becoming less and less convinced of my own beliefs simply by reading Steve’s support for those beliefs! The problem is that Steve supports this rather contentious view by providing a positively ebullient account of life as a Google employee. If that is the support, then I’m afraid the argument is tremendously weakened.

Steve describes Google as a cross between a startup and grad school. The system works by letting self-motivating people work on the things they want to work on. If they’re having an off-day, that’s okay because a good person working on a problem they are innately interested in will get more done on their good days than any person forced to work on something they are not interested in every day of the week. Now, take that person working on something they wouldn’t voluntarily work on, what can one expect from a good day for that person? Will their productivity soar to the same staggering heights as the self-selected contributor? Or will they rush through their work for the day so they can put their energy into what they’re really interested in (e.g. open-source projects)?

Clearly, Google’s position is so extreme as to make it a dubious model to follow. The apparent effects of staff quality, benefits, etc. all stem from the fact that Google has a Scrooge McDuck sized pile of money which enables them to provide mobile financial bubbles to protect their engineers as they interact with the rest of the world (I have visions of Bubble Boy, but with more programming). Google can do things nobody else can, in a way nobody else can, because they have a cash cow (AdWords) that minimizes (eliminates?) the external demands placed on any other project. Let’s agree on that and get past finances.

Steve says that Google’s interior design facilitates meetings and pair programming when necessary (“say 5% of the time”), so why do other companies think they need so many meetings, and why are they always looking out for the next fad diet methodology? I think the difference here is entirely predicated on the fact that Google’s employees are working on the projects that they want to work on. To be clear, if you took the worst programmer you’ve ever come across and got them a job at Google, they’d be more likely to sink than swim. But if you took a great programmer from Google and forced him or her to work on the worst programming job you’ve ever come across, how would they do? I contend that they wouldn’t be quite so self-starting in that context. I would also contend that meetings may sometimes be necessary to keep that great programmer focused on the job at hand. Heck, maybe pair programming could even be useful to smooth out the unevenness caused by the good day / bad day cycles. I do believe that a smart person can actually find something interesting in almost any endeavor, and that a good programmer would get the job done no matter how boring, but I do not think that programmer would be producing at his or her top level.

To be honest, I really hated writing the above because I can’t stand meetings, I don’t hold any of the overly-formalized Methodologies under discussion in very high regard, and I am most definitely not an early riser. But, for all that, I can only say that I get more done if I’m not arguing about what belongs on an index card and what doesn’t. Steve’s post made me realize how silly a comparison it is to compare a project of the heart with a service provided under contract. Google is perhaps run in just the right way for Google, but that is by no means an indictment of any other way of doing things.

Expect an upcoming post to denounce meetings, index cards, etc. :)

Share
Categories: Programming, Software Design Tags:
Comments are closed.