Feature Driven Development

Jim Highsmith has an interesting thesis that we are moving away from an era of planned (envisioned) products towards one of evolved products – evolved in a similar sense to evolved living organisms. He argues that evolved products are often superior.

I don't want to overdo the comparison to natural organisms but Highsmith fails to mention that natural evolution is often extremely inefficient and wasteful and frequently ends up with mechanisms that no-one would rationally choose were they to design a solution (with a full understanding of the problem). Richard Dawkins in Climbing Mount Improbable explores this issue and explains the reasons using a number of examples including the eye positions of some flat fish. I think the reasons are interesting and relevant to the Agile development community. Coincidentally I have been a critic of the XP crowd on precisely this subject.

Richard Dawkins explains how natural selection (evolution) always builds (and must always build) on what has come before. Its the accumulation of many small incremental changes (see the similarities to XP) and can achieve truly wonderful outcomes like the human eye. However, if you were designing a human eye from scratch there is no way you would design it the way the human eye actually works because the design is fundamentally flawed, and that fundamental flaw results from the eye evolving through small changes from an earlier simpler design (I use design loosely).

It is my contention that this is an inherent and serious problem with the no-design-up-front schools of Agile development, i.e. evolving from simpler mechanisms frequently results in less than optimal (and not infrequently deeply flawed) end products. The XP crowd would counter that they solve these kinds of problems through refactoring, but I believe refactoring has serious limitations for the well understood reason that the further you are into code (and deployment) the harder it is to change things. Perhaps the main reason I am an FDD proponent is precisely because FDD tries to solve these fundamental design issues up front through domain modeling.

To complete the natural selection comparison, in the real world of evolving organisms the ones that have flawed designs are more-or-less quickly (on evolutionary timescales) replaced by organisms that have a better design. This leads me to conclude that Agile methods that don't do up front design have advantages in the short term but are at significant risk of evolving product dinosaurs that consequently share the same fate.

Highsmith also uses the exploration metaphor which I find interesting as many explorers became failures because they didn't find what they expected to find such as Christopher Columbus who was searching for a new route to the Indies. The moral being, its not enough to discover new things, what you find has to be something your client values. I think much of the Agile community has things to learn on managing client expectations, not least visibility of the end result. Again FDD stands out as the exception among Agile methods in this respect.

On a more substantive note, the book (or at least the parts that I read) has the same flaw that much (almost all?) of the published writing on Agile shares. Namely it doesn't recognize there are limits to the applicability of any process. We all know that Agile processes work well, but we need to recognize that there are situations where they don't work well (and some work better than others). Missionary zeal was appropriate in the early days of Agile, but maybe its time to be more dispassionate and recognize Agile's limitations and failings. I for one, are still waiting for the definitive analysis on Agile processes - when do they work, where do they work and why do they work.

Not withstanding the comments above, based on the chapters I read, this is an interesting and worth reading book.

Phil