The Cost of Fixing Defects

Steve McConnell wrote a great book about Software Engineering called Code Complete.  If you're not a Software Engineer, I wouldn't recommend it.  But if you are, read it now!

But there are 2 really excellent points in the book, even if you are not into Computer Science (really!).  The first is the subject of this post: the exponentially increasing cost of fixing defects as you progress into the development cycle.  It looks something like this:

Along the bottom are the various phases of developing a piece of software.  The far left signifies the early stages and the far right, the stages after deployment.

The chart above actually leaves out a preliminary stage that I always start with: the problem statement.  You can't solve a problem unless you know what it is.  This fundamental truth is all too often forgotten as people rush into a "solution."

The idea is that if you catch a problem in the first stage, which is simply the conceptual defining of the software, it costs 150 times less to fix than if you wait until the final stages.  150 times! 

The idea makes intuitive sense.  What is surpising in the scale of the difference. 

Now, I promised this would be interesting outside the scope of Software Engineering.  I think you can see how:

This same principle applies all around us.  Often we rush forward into something, only to realize a flaw in the early stages of the venture that is now costly (or difficult, or painful, or annoying... or impossible) to fix.  Or if the flaw was in the very definition of the problem, we have now wasted a tremendous amount of energy pursuing a "solution" to the wrong problem. 

I have most often observed this in discussions that turn into arguments.  A simple misunderstanding of a term or idea initiates a useless argument.  One party says something and means one thing.  The other party thinks he meant something else, and off we go!  Hopefully the one with a cool head eventually realizes they are talking about different things and the whole thing is passed off as an exercise in futility, getting nowhere.

So let's now apply our SE principle.  If, at the outset of this discussion, one could actually take a step back and define the nature of the disagreement, likely they would realize it was a simple misunderstanding and no argument would take place.  

How do we do this?  The Bible writer James tells us to be "swift about hearing, slow about speaking."  Oh, if we could only apply that!  Instead of being so quick to support our case, why not ask a question to clarify the other side?  And then listen to the answer!  

I can't tell you how many times this has aided me at my former job and even now in casual discussions.  So often we find that there is really no disagreement at all.  Or, equally importantly, that the disagreement is completely different than we initially understood it to be.  In either case, we save ourselves a huge amount of effort and time.   

Again, we cannot solve a problem if we do not know what it is. 

Now, I mentioned there were 2 great points from this book.  We just talked about the first.  The second is Broken Windows.  I will save that for another time.