UPDATE from Alex of 2012: Ouch. In retrospect, this article is pretty awful. The author (the Alex of 2007) had been largely mis-informed by charlatans: those Agilistas who claim "agile" was a goal of the development organization that was achieved by consuming only small amounts of the business domain at a time (hence the flawed pyramid analogy).

Five years later, it turns out Agile is not that at all. It is a business mindset that requires the business to think smaller and sooner; only after that can the development organizaiton adopt smaller, sooner changes. Hopefully, five years from now, this will just be the way that all software is developed.

Many years back, I got hooked in to whole the Atkins Diet craze. And like most dieters, it didn’t work. I lost weight and slowly gained it back over the next few years. The reason that Atkins – and all the other fad diets – fail is because they try to avoid a simple, painful truth: short of altering body physiology, the only way to lose weight is to eat less and exercise more.

In the past decade or so, we’ve seen a lot of “fad development methodologies” crop up. In lieu of a standard Worse Than Failure article, I'd like to discuss the latest craze (well, for a few years now): Agile and its derivative methodologies. They all promise the same thing – cheaper, better software built faster – and they all generally fail to deliver. Like fad diets, these methodologies try to avoid a simple, painful truth: you have to know what to build before you can start building it.

A whole mini-industry had spawned around the Agile methodology – books, seminars, consultancies, you name it – and there’s really no succinct way to discuss all of the specifics. Instead, I’ll simply present a single problem: The Pyramid Builder’s Dilemma.

I’ve seen this analogy presented in a handful of seminars and used in articles and books. So far as I can tell, it originated in John Mayo-Smith’s Information Week article entitled Two Ways to Build a Pyramid.

Two pyramid builders – Goofushotep and Gallanthotep – set out to construct a pyramid for their pharaoh. Being the traditionalist that he was, Goofushotep build the pyramid from the ground up and risked not finishing it before his pharaoh’s death. Gallanthotep, the Agile architect, built a small pyramid first and built additions sideways, so that there was minimal risk in having an unfinished pyramid when his pharaoh died.

This analogy is apparently used to show how Agile methodologies expect and adapt to sudden change (the pharaoh’s untimely death). But I think it’s a much more apt analogy for what happens when we try to build software this way.

  • First and foremost, it’s probably not even possible to build an Egyptian-style pyramid sideways. A pyramid is a three-dimensional shape (the diagram/analogy assumes it’s a triangle), and adding to a face would make it ruin its nice, square base.
  • Secondly, a foundation must be laid prior to construction. I would imagine that constantly changing and adding to the building’s foundation in the middle of construction is a bad idea. I doubt such a building could last a few seasons, let alone a few millennia.
  • Thirdly, the intricate tunnels, rooms, and corridors within a pyramid would be pretty hard to plan out if the size of the building constantly changed. It’d probably end up looking pretty ridiculous once the pyramid was finally complete.

Perhaps I’m being a bit unfair nitpicking an Agile analogy. After all, the Agilistas contend that it works well and have whole handful of success stories to show for it. As for the cases of failure, the answer is overwhelmingly, “of course it didn’t work; the project didn’t have enough good people.”

And therein lies the problem: most developers are not good. By the very definition of the word "good," most people are average, below average, or just plain suck. There’s a word to describe products designed for the masses that work only for some: defective.

Good people can build good software no matter what methodology they use. We don’t need a weight-loss pill for thin people; we need to solve the real problem behind failure in our industry. The bar for “acceptable” is far too low. We need to focus on improving the skills of the less-than-good in our industry.

While improvement in anything is certainly a laudable goal, these methodologies are a distraction and hampers this objective. Like miracle pills, Agile fosters the illusion that the quality problem is solvable with a simple change in process. Why go to all the trouble changing people when one can simply change process?

I do realize that a lot of developers (many of whom are my close friends and colleagues) claim to have a found a lot of success building software the same way that Gallanthotep builds pyramids. But for the overwhelming majority of software (i.e. complex information systems with a lifespan of at least fifteen years) and the overwhelming majority of software developers (i.e. the less-than-good folks), Agile methodologies simply cannot work.

Remember, the fact that a system that makes it to production does not mean it's a success. We need to build our systems so that our successors -- developers with less business knowledge and a weaker grasp of the system’s design -- can build on and maintain them. We need to educate and train the less-than-good and raise the bar for acceptability. No, it's not the easy way, but it is the simple, painful truth.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!