While I was at Codeworks DC in September 2009, there was a particular slide during the talk by Stefan Priebsh, in his talk on OOP and Design Patterns that stood out more than all the others. It’s a slide that describes the relative cost of of a bug fix at different times in the life cycle of a software project. At first, the cost of fixing a bug at the requirements stage is nominal, when everything is on the drawing board. But as the software moves along in its life cycle the cost of fixing a bug increases radically. We start at 1 times when we are at the initial development stage when a bug is no more than a change in notion. But at the design stage, the relative cost is 5 times what it was compared to the requirements stage, and then ten times what it was when it becomes code and on this goes until it the relative cost of a bug fix is 150 times what it was originally. Conversely, the graphic indicates that the cost of rewriting is far less than attempting to maintain broken software. Starting right, or starting over right, is by far preferable to the alternative.
Relative Cost Of A Software Bug Fix
Slide credit: Barry Boehm, “Equity Keynote Address” March 19, 2007.
This chart is intended for developers, to decide how best to spend ones time. Ever wonder why, as a developer, fixing bugs is such a pain and a kludge? There is something not simply tough about fixing bugs, there is something fundamentally wrong about putting any effort at all into repairing them. But the chart is also a message to the paying client, the person whose dime it is on. A client may be only thinking in the short term to make the software work, but it is the most expensive and unproductive path to the realization of goals.
The effort to fix bugs is great and the rewards are minimal. Frustrations are high, satisfactions are low. The website suffers from some sort of performance penalty, users are inconvenienced. Bugs must be dealt with with some amount of procedural overhead no matter what, and when the bug is fixed and submitted, very little was ever really accomplished. It is really far better to think of a better solution to all your problems together rather than to continue fixing things one at at time. It will cost the customer less and they will get more. So when bugs become a staple of the work load, its time to persuade the client to accept a rewrite.
…with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. Its as expensive to do as it can possibly be.
Developers still have a great deal in common with the clients they perform work for. They charge money for their work so they think in terms of the cost in terms of labor time (actually, developers also think this way when they work on their own software). The question every developer asks is, “What is the simplest, easiest, and fastest way to get something done?” The answer could be open to interpretation, but that is because the long view must be taken into consideration, and that is why software makes use of functions, templates, classes, objects, and design patterns. The work is needed now, but how will it be possible to understand the software in a few months time when noone is mentally fresh? How do I share my ideas with other people? How do I take the long view into account?
Despite the love a client may have for their own project, nobody is interested in working on the same software forever. After all, software developers are creative people who really want to expand their skills and take all that they have learned and apply it to the next project, instead of keeping something half dead on life support.
I enjoy attending talks from the best people in the world in my business, because they are very good at exposing the importance of planning and organizing the overall picture, and are very knowledgeable in all the concepts that make projects produce a top quality result in an efficient manner. They also point out the simple mistakes people make that cost them so much. When we are at the far right of the graph, with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. Its as expensive to do as it can possibly be.
Developers should try to understand the message of this graphic before going further fixing bugs. If you are put in a position fixing bugs, it is time to change the way you work, because you are the one bearing the cost in terms of your own time performing the least valuable, most expensive, and least meaningful work.
