Advertisements
Posted by: jsonmez | 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.

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. a great post, clean code is better, easier to read, and maintain, but it is also diffecult to write well, and takes practice, its something we developers just have to get our heads around.

    sorry, both the links point to the same posts by John. Bob Martin’s post is at
    http://thecleancoder.blogspot.com/2010/09/john-macintyres-clean-code-experience-1.html

    • Thanks! And thanks, I updated the link. Copy past error 🙂

  2. I agree with what you wrote.

    Knowing that “doing the right thing is not always right”, after investigating a bug that has been assigned to me, I always ask the team leader whether he wants the fix to be clean or dirty. Surprisingly, most of the time, he has gone for the dirty fix. Go figure!

    Eddy.

    • Hi Eddy,

      I’m not quite sure I agree with going for the dirty fix, unless there is a really good reason like $ are actively being flushed down the toilet while the bug is in production, even then I ask people to calm down and think about if a dirty fix could cause more problems down the road which will lead to more of these kinds of decisions. But, sometimes you have to do what you have to do.

  3. hi there, nice article and tehre are some interesting points, and althou I like new shiny as much as the most as I read this, you seem to imply that c# equals clean code. Not true, you can write crap in every language.
    Also you are saying that you suggest a rewrite even thou it doesnt seem to make practical sense… I would suggest you have a look at Working Efffectively Witth Legacy code, I d say most times you ll get a better result by putting safety around code that is there an works and then building on top
    For example you can write integration tests that test the current code as is, then create wrappers around it (and have the tests still passing) so you can consume it in a way that makes sense from new code, and then build on top of that. This is real hard work however the work is shorter and the team can move on into new , easier to test code. No silver bullet, but sometimes its just more work.
    My two cents 😀

    • Hi Andrea,

      I definitely do not mean to imply C# code is clean code. Certainly the language choice has nothing to do with code being clean.

      I agree with you about Working Effective with Legacy code. The point I am trying to make by suggesting a rewrite of a VB6 app to C# is that it may actually not make sense from a business or practical standpoint, but because it so motivates developers, because it is shiny and new and in a better language, the results may actually end up being much better than anyone would have guessed.

      I use VB6 and C# as an example here, because I feel that many developers have had the experience of having an old VB6 app that they hated working on and wished they could rewrite in C#.
      Thanks for you comments.

  4. Great article, I completely agree. I’ve seen first hand how terrible code kills motivation of a development team.

  5. […] El código limpio: ¿Es arte o ahorra dinero? […]

  6. […] Clean Code, Saves Money or Is Art? Making the Complex Simple (tags: programming) […]

  7. “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.”

    So true. Meeting business needs comes first and foremost, but code quality is important as well. Slogging through crappy code day-in and day-out is severely demotivating, regardless of how pretty the finished product looks on the outside.


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: