I know that you, dear reader, have come to expect a certain level of sophistication and journalistic integrity when it comes to my monthly pontifications: A gloss of civility, a certain level of refinement, and an even airing of all sides of an issue. Thus, on those very rare occasions when I have a personal opinion to present, I feel the need to make my viewpoint on the issue under discussion extremely clear. And so it is for today‘s topic: Agile software development methodology.

Let me start, then, by clearly, dispassionately, and logically describing my point of view:

Agile software development methodology sucks ass. Big time. Totally. 100%. Entirely.

Gosh, I hope I‘ve stated that clearly enough.

Let me explain further: I have never, not once, not ever, participated in, seen, or even heard of a project in which Agile works better than any well-organized alternative. Agile is without question the refuge of those with small minds, poor writing skills, and extremely high-levels of tolerance for incomplete functionality that‘s written in a way that‘s "good enough" to pass whatever tests happen to exist.

Just to make sure that you understand that I mean to slag the entire, wide-ranging, genre that is Agile, I specifically mean to include Agile permutations like Scrum. Basically, I mean to include any software development methodology that relies on references to barnyard animals, where you stand-up to have meetings, or where you‘re supposed to account for what you‘re doing in units of, like, 45 minutes.

My major objections to Agile come from what I view as the unmitigated stupidity of its three most important tenets:

A maniacal emphasis on "just getting something working" as opposed to thinking something through, designing how it should work, and getting something working correctly.

Requiring detailed estimates of how long it‘s going to take to implement some piece of functionality.

An insane reliance on – and limitation to implementing features for – user stories (AKA scenarios), which yield fragmented feature sets as opposed to designing for well-reasoned comprehensive functionality.

For the life of me, I do not understand why I would ever want to write code for a complex facility before I have had the chance to design that facility and consider how it will interact with everything else in its environment. For sure, managers like it. They think designing things is a waste of time anyhow. This reminds me of clients who tell me to «just write some code» to do so-and-so. I work in kernel-mode, boys. I often work on complex pieces of larger systems. It doesn‘t make a lot of sense to just «write some code» that‘s «good enough» – when you do that, you get code that doesn‘t handle corner cases, doesn‘t work or play well with others, and is generally ill-conceived.

But Agile is all about «just writing code» System architecture? Design? In Agile, that‘s not in the plan. What‘s in the plan is «code it up and see how it works» and «you can fix it in the next sprint» That‘s hosed. It‘s a waste of time. And while I‘m all about «plan to write one to throw away», I sorta think that the word «plan» is important there.

Ever build a house? ...

(continued on page 5 of The latest issue of The NT Insider (July/August 2010) is now exclusively available for download in PDF format.)