By John Sonmez May 10, 2010

The True Cost of Quality Code

I saw a tweet by Robert Martin (UncleBobMartin) this weekend that said:

The problem is that people think that code quality is a short term loss but a long term benefit. They're wrong about the first part.

It is kind of funny because I had just a conversation with a friend about whether or not actually doing test driven development is too costly.

quality code

Both viewpoints can be correct

To be honest, I have seen it argued both ways, and both can be correct:

  • Code quality is a short term loss
  • Code quality is not a short term loss

I have found that often, out of seeming contradictions, comes the most wisdom.  There is a piece missing from the equation here.  The piece that is missing is the experience of the developer in code quality best practices likes test driven development, self-documenting code, SOLID principles, etc.

If you take an average team of developers that have some familiarity with these kind of code quality best practices and require that they consciously follow them with every line of code they write, you will end up having a short term loss in productivity, but will end up with a long term gain.

If you take a team of developers who are used to writing tests first and applying other principles of code quality, and set them loose on a project, having them use those principles, you will end up with both a short term and a long term benefit.

A complex equation

There is an equation which can be used to demonstrate the benefit of quality code over time.

Let Overhead represent the overhead it takes for a developer to write quality code vs fast code.  100% would be same time.  120% would be a 20% overhead, etc.

Let QSavings represent the average savings in time for having quality code.  (This represents savings from maintainability, less bugs, readability, etc).  100% would be no savings, 80% would be a 20% savings.

Let PTime represent the total length of the project in weeks.

PTime – (PTime * Overhead * QSavings) = Saved Time

Let's look at a 6 month project where developers have a 200% overhead for writing quality code, and the quality code gives a savings of 60%.

24 – (24 *  2 * .4) = 4.8 weeks

On average I would say that developers who are not used to doing things like writing tests first, will incur a 2 times overhead in writing quality code.  Over time this number actually diminishes, so long as they are strict about writing quality code.

If we take that same 6 month project and use developers that have only a 120% overhead for writing quality code, and the quality savings bumps up to around 70% because of their experience we really save some time.

24 – (24 * 1.2 * .3) = 15.36 weeks

Those numbers seem a little crazy.  Can a team of developers that are good at writing quality code really take a project down from 24 weeks to 9 weeks?  Yes, indeed I have seen it happen many times.  Those developers just have to be 3x as effective as normal.  I have seen it said that the difference between a great developer and an average one can be 10 to 1 ratio.  3x should be easily achieved.

Now I am using some fake numbers here in the equation, but let me justify a few of them for you.

First, the most controversial.  60-70% savings for having quality code.  Is that number real?  I tend to think it is.  When you look at the cost of fixing a bug at various stages of software development, it becomes pretty apparent that not producing a bug in the first place, or catching it when writing the code, can have savings that are easily 20x.

The typical overhead I have seen for developers that have never written unit tests is around 300%.  As they become more familiar with unit testing, mocks, and other techniques this drops to around 200%.  It is not until several years of practice that someone can achieve a small overhead like 120%, but it is definitely possible.

So, although the numbers are made up, they come from estimates based on my personal experience and what I have heard from others.

Technique takes practice

When I was a kid I remember my dad teaching me the right way to hold a baseball bat.  I didn't like it because it wasn't what I was used to.  It even made me a worse batter because the wrong way, that I was used to, was easier for me.  I had to practice the right way for a long time before it got me past the limit of how good I could get doing it the wrong way.

I had the same experience in high school as a pole-vaulter using a straight pole vs using a flexible pole.

I still type the wrong way and because of that I will never be able to type 120 words per minute, like I would be able to if I spend the time to relearn my typing.

Almost all professional bowlers use a hook.  I don't know how to bowl with a hook, but I can perform decently without one.  If I tried to bowl with a hook, I would be worse at first.

I've heard of golfers hitting a wall and having to completely re-learn their golf swing to get past it.

Why would we think it is any different with programming?  Yes, a person can be fast and a pretty good at writing code the “wrong way,” but they will never achieve the speed and accuracy that is possible by learning the correct techniques.  It takes time and practice for this to be achieved.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."