The question for the day: will Agile violate a widely held principle behind software economics? And perhaps more importantly – do we care?
The principle in question is the Pareto Principle, aka the 80/20 rule.
Among other things, the Pareto Principle (http://en.wikipedia.org/wiki/Pareto_principle), describes the ratio of software maintenance costs to development costs, stating that the vast majority of the costs invested in a piece of software comes during maintenance. The 80% isn’t a strict number in this case as various studies have produced a range of figures – see http://users.jyu.fi/~koskinen/smcosts.htm, but the rough weighting of the Pareto Principle still holds.
Here’s where I see an Agile perspective might have an impact on these things:
- Agile projects will attempt to get to production much earlier than their traditional counterparts
- Code produced with an Agile level of technical discipline will have a much higher level of internal quality, which should lead to reduced time needed for defect fixing during maintainance and increased productivity for enhancements
In essence, these two forces are opposing: faster time to market should lead to a larger percentage of cost expended on maintenance costs while a cleaner codebase should decrease this amount. Which force will have a greater impact? Who knows.
To answer my own question, I don’t think it really matters what the net effect of Agile has on the relative amount of software maintenance costs. Instead, my preference would be to remove the classic distinction between project and maintenance work which seems to be based around financial drivers like budget allocation from either capital expenditure (capex) and operational expenditure (opex), and to move to an ongoing “product” view of software which doesn’t distinguish between initial development and ongoing work (hint: will be posting soon on this).
Still it is mildly interesting to ponder the bigger picture ripples Agile may cause in the software development pond.