We are collectively flushing the money down the drain.
Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted – it should be spent on writing the right software.
Background
Joe Marasco, CEO of Ravenflow, has written an article where he posits that we’re making bad investment decisions when it comes to improving our ability to create successful software. He’s provided data to support is argument.
The Standish Group, in their CHAOS reports has shown dismal software project success rates for the past decade. Digging into the details reveals 40% to 60% of the problems are caused by bad requirements.
Even when we know the problem is with our requirements, we also know that requirements management software will not solve the problem.
Problem Validation
Joe has the brilliant insight to recognize that with three CHAOS reports, we can produce a graph that shows a (possible) linear trend in improvement of a little over 1.5% per year in software project failure rates.
With roughly $250 Billion being spent on software projects per year, we are collectively seeing just over $4B in savings per year. Not a very good ROI for our projected $4B investment.
What if the linear assumption is wrong? We know half of the problems come from bad requirements, so there should be a limit to what improved coding efficiency can do. The graph may look more like this.
In that case, we’re about to have a negative ROI. Investment keeps going up, and results keep getting smaller.
Lies and Damn Lies
Joe asks “why so little improvement per year?” and raises an interesting point. Perhaps we are solving harder problems and achieving more value with fewer resources as we get more efficient at software. There is no way to reach an empirical conclusion on this, but we think he’s right – we are doing that. But we also think the law of diminishing returns makes the asymptotic curve more likely than the linear.
Engineers and Artisans
One reason that we are not improving faster is that software engineering is not engineering. [I say this as a former registered professional engineer]. Software engineering is requirements + code + test. Only coding and testing have elements of engineering in them. Requirements managers are artisans.
Software developers are making progress in abstraction and re-use. We don’t write in assembler any more. We have code libraries available to minimize reinvention, even in higher level languages. Software developers are becoming more like engineers every day as their behavior becomes more an element of applying existing code than writing new code.
Requirements writers bear no resemblance to engineers. Like carpenters hand-crafting furniture, we have little or no reuse in our process. We are artisans. Since we are addressing a “new” problem with each project, we may always have to approach things as artisans.
Becoming Better at Requirements
We’ve shown before that having better tools for managing requirements won’t improve the quality of the requirements any more than a better saw improves the quality of a custom cabinet. Faster and easier, yes. But not better. Artisans improve with training and experience. This approach makes sense as the best one for improving at writing requirements.
Over the last month, we’ve written a series of 10 articles targeted at writing better requirements. The focus of this series is specifically on improving MRDs, and the linked article contains the summary of all ten, as well as links to the individual articles. Topics like removing ambiguity, validating the content with stakeholders, confirming feasibility with development – all key to preventing errors.
Conclusion
We should be investing more of our time improving our ability to write requirements, and write the right requirements. Maybe we spend so much on becoming more efficient at writing code because we know how to do that.
A plant manager can easily rationalize spending money to make his assembly line run faster. He understands the problem, and can measure the results.
$4 Billion dollars are being spent trying to solve half the problem. Imagine what would happen if we took just 25% of that, and spent it trying to solve the other half of the problem?
In fairness, our industry isn’t ready to absorb that kind of investment yet, so we shouldn’t make such a dramatic shift. How about 2%?
Latest Articles
Comments on all Articles
