By John Sonmez September 21, 2010

Clean Code, Saves Money or Is Art?

Lately there has been a lot of chatter about whether writing clean code actually saves money or whether it is more about art, i.e. making things pretty.

(See John MacIntyre’s post here if you are interested, and Uncle Bob’s response here.)

Well, as Forest Gump would say,  “Maybe it’s both.”

gump

How can it be both?

I think overall writing clean code saves you money to build software.  (Unless the time you are going to spend maintaining the software is minimal or non-existent.)

The reason why it saves you money is where the both part comes into play.

If we just extracted the money part from the practice of writing clean code, we can make a pretty solid argument that overall it saves money by looking at what costs the most time and money in software development.

Go ahead take a guess.  What do you think it is?

That’s right.  Fixing a production bug. It may take awhile to write unit tests.  It may take awhile to refactor you code to be “clean.” But, if spending an extra 3 hours on a 3 hour coding task ends up saving you just 1 production issue, you’ve made your time back and then some.

The actual time expense of a production issue, all the way down the line, from project managers to QA to programmers to back to QA and back to deployment can easily cost 10 or more hours per issue, easily.

It’s really hard to argue against that logic by itself, but there is another element that comes into play here.

The human element.

You see it’s not all about dollars and money and what makes logical or practical sense when you throw humans into the mix.  I believe if the non-human benefits writing clean code didn’t save you any money, overall it would still save you money.

Let me explain.

No one takes pride in crap

I don’t care if the software works or if it looks pretty on the outside.  The person maintaining that code is going to have a different view of it.

If the internal code is crap, if it is nothing to feel good about, if it is a big pile of spaghetti code, it is going to severely demotivate developers.

And what do demotivated developers do?

All kinds of horrible things.  They look for new jobs.  They write more crap code.  They waste time and stall.  They do what they have to to get by until they can either get the heck out of this stupid profession, or that dream job comes along where they can write ASP.NET MVC code using an auto-mocking container and BDD.

Sometimes you have to ask yourself, is it really that much more difficult to maintain that existing VB6 app than if it were converted to C#?  Seems like it shouldn’t be, right?  It definitely is easier to maintain a nicely built C# application, but there is a compelling reason why those applications eventually get rewritten, even though they really might not need to.

Developers working on old crusty applications just are not motivated to do so.  Developers like new shiny technology.  They like to feel like they are learning and expanding their skills, not just maintaining status quo.

So even though rewriting that VB6 application doesn’t really make practical sense… even though your metrics and charts tell you that you shouldn’t do it…  When you do rewrite that application you will find this magical hidden cost savings, because suddenly developers won’t drag their feet trying to fix a bug or add a feature to “that crappy old VB6 app.”  To the customer that application might even look exactly the same, but to the developers working on it, it will be a brand new shiny toy.

Writing clean code is about more than saving money

So you see, in the theoretical there are argument about whether refactoring that code will actually be a positive return on investment or negative.  I’ll argue for the positive on purely practical and chartable theory every time, but when you throw in the human art element, it is no contest.

If your code  base is something that your developers take pride in, you will see huge savings in time, because your developers will be significantly motivated to make it even better.

Clean code begets clean code.

So when I say it is both, I’m not just being non-committal or luke-warm about the topic.  The human element makes that fact that clean code is art important to saving money.

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."