September 4, 2007
Cost of Change Curve Is Really A Spectrum?Today my brain is fixed on the old cost of change curve that underpins two competing schools of software development.
The defect prevention school argues that the cost of changing software rises exponentially the longer you leave it, and you should therefore stabilise requirements, designs and code as early in development as you can. Basically, this is the "make and test your decisions as early as you can" crowd - sometimes known as Big Design Up-Front.
The Agile school argues that - with shiny, spangly new methods and tools - it's possible to flatten the cost of change curve, and you can therefore benefit from the ability to defer decisions for as long as possible, leaving a wider solution space to work within, with all the statistical advantages that can create.
The Boehm model of exponentially increasing cost of change is corroborated by a whole heap of statisical evidence drawn from thousands of projects over the last few decades.
The Beck model of a flattened cost of change curve is still only backed up by anecdotal evidence. But a lot of folks seem to believe in it. (Like alien abduction, I suppose).
Scott Ambler suggests that the reality is a bit of both. I tend to agree. In fact, I think it's a spectrum. Some projects are very, very Boehm, and some are very Beck. I don't think any are completely one or the other, as these are extremes that I feel might be highly improbable - and therefore very difficult and costly to achieve.
It lends further weight to the argument that a bit of Up-Front Design followed by a very healthy portion of Crossing-That-Bridge-When-We-Get-To-It might be an affordable and effective balance. Not every project will sit in the same part of the spectrum, and figuring out where we fit into the grand scheme is arguably half the fun. (Okay. If you're an ivory tower jockey like me then it's all the fun.)
Posted 13 years, 10 months ago on September 4, 2007