Advertisements
Posted by: jsonmez | May 10, 2010

The True Cost of Quality

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.

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 able to 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.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.
Advertisements

Responses

  1. That is an excellent point, but as I was thinking of your examples it raised a question for me:

    What if bowling without a hook you were already bowling a near-perfect game? I don’t know a whole lot about bowling, but I know a perfect game is 300. Lets say you were already bowling a 285. Would you still say that the person should learn to bowl with a hook?

    As that applies to the main article, what would you say if a developer were writing code in what you consider to be the wrong way, but they’re very very good. Would you still want them to change their method?

    • Very good point. Here is my thought on that. For bowling, someone would have to weigh the cost. If you wanted to be able to bowl that 300 game, it would probably be worth the effort of retraining yourself to bowl a different way. If you really wanted to go pro.

      I seriously doubt someone could be so good that they would write quality code without using generally accepted best practices, but lets assume they could for a moment.

      The difference with programming is that development is a team activity, someone else has to read and maintain your code. So even if you can hack out complicated bug free perl code. If no one else can maintain or read it, it is going to have a net impact of a negative effect.

      • Excellent point; viewing it as a team sport really brings it into perspective. If the whole team isn’t playing the same game it would make it impossible to unify effort.

    • I think the bowling analogy still holds. The reason good bowlers bowl with a hook has to do with the physics of the whole thing. Hitting the pocket at a slight angle (6 degrees sounds familiar, but don’t quote me on it) will consistently yield good/better results – mostly strikes when things go right and not horrible splits when things are slightly off. The keyword here is consistently. A bowler that throws the ball straight will have a very hard time consistently bowling that 285 (I’d go as far as saying they’d have a hard time keeping it above 200). Back to the realm of development, it is possible for someone to hit that ‘285’, every now and again, by using some suboptimal approach (whatever that may be), but the odds are against them maintaining that level of quality/success over time. In other words, the goal is not to write excellent software every now and again. Its to develop and employ approaches that allow you to consistently write excellent software.

  2. […] The True Cost of Quality (John Sonmez) […]

  3. I can not agree more. 🙂

  4. […] The True Cost of Quality (John Sonmez) […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: