You can always find someone to argue for cutting quality corners to "go faster". Is it possible to waste time cleaning code? Sure. Is it possible for code to be too clean? No.

What is “clean code”? Millions of words could be written, and we would agree with none of them. Yet professional programmers all around agree when they see it, and agree more strongly when they see bad of dirty code. For a long and excellent description of clean code, see Bob Martin’s book. For our purposes here, let’s just follow Kent Beck’s rules for simple code. For now, code is “good” if it:

  1. meets the requirements (runs the tests);
  2. expresses all the design ideas we put into it;
  3. contains no duplication;
  4. minimizes the number of components.

We’ll not explain these items in detail here. Search this site and many others for discussion of these elements. They’re just here to give us a common footing.

It turns out that applying these rules tends to generate code that is good by other common definitions. For example, expressing all ideas and removing duplication tends to generate code that is highly modular; code that is highly cohesive, and loosely coupled.

Clean Code Goes Faster, with Fewer Defects

When we are faced with a change to code that is not clean, two bad things happen. First, there are many places in the code which must change: these are shown in the picture below as orange bits among the code. Second, we have to tiptoe through a complex map to change them all, and all too often we accidentally step where we should not.

Horrible path through bad code

On the contrary, when the code is clean, two good things happen. First, a given feature requires changes in fewer places. Second, it’s easier to find our way among the places, and easier to avoid stepping in the wrong place.

Nice simple path through an organized space

Good code makes our job easier. Changes made to good code go more quickly and produce fewer new errors. This is a good thing, and I expect no dispute so far. (I assume this means that I’ll be attacked on this point. Be aware that I am prepared for nothing, and therefore prepared for anything.)

Can Code Be Too Clean?

In a word, no. Code cannot be too clean. The cleaner the code is, the faster and more reliably we will go. It cannot express its ideas too well. It cannot really contain too little duplication. It can’t really be too cohesive or too loosely coupled.

Oh, OK, it might be possible. Perhaps you could take a month and write code that is so good that making it worse would make it easier to edit. If you did, we would mock you for two reasons:

First, since it would be easier to work on if less clean, we would all refuse to accept that your extra-clean code was actually more clean. Second, we would abuse you for spending a month doing it.

And that’s a more important question:

Can We Spend Too Much Time Making Code Clean?

Here, the answer is yes. If we take a week trying to think of the perfect name, that’s probably bad. Taking only four days to get a really good name would be better. Taking ten minutes would probably give us a very acceptable name.

We have an important pair of results here:

  1. It is not possible to go slower because the code is too good;
  2. It is possible to take too much time making the code good.

How Good Should We Make It?

We’re back at the crux of the question, I hope with a better understanding of the issues. We really do like the code to be as clean as possible: and we really do know that we could spend too much time making it clean. In particular, when can we actually go faster by coding less cleanly?

Remember that there are two components to the problem with dirty code. One is that it is harder to change. We might be working on code that is not going to change. The other is that when we work on dirty code we put in more defects, and defects are harder to find and remove than they are to prevent.

If we are writing a sufficiently easy on-off program, then there may be no point to making it clean, surrounding it with tests, and so on. Someone on twitter suggested that a one-off script of twenty lines might be an example where clean code doesn’t matter.

Except when it does.  I’ve seen a quick twenty line script wipe out a database, require a reload and rebuild, and cause days of delay to a whole project. That one needed more work.

The trick is knowing the difference.

We Have All Gotten Away With It

Sure, I’ve written code that wasn’t clean, and I got away with it. The thing worked and if it was a bit hard to work with later on, well, it was worth it because we got it out there so quickly.

This is post-hoc analysis. When I pass someone at high speed on a two-lane road, into oncoming traffic, the fact that I live is not evidence that it was a good idea. I know this from the way my wife reacts when I do it.

To pick another car analogy, the fastest way around the race course is smooth and clean. Those drifter guys look fancy, and burn a lot of rubber, but their time around the track is very poor compared to a real racer. Smooth and clean pays off. Dirty, not so much.

As far as I know, there is no credible evidence regarding when, if ever, slacking on code quality makes us go faster. As individuals, on top of our code, we can probably go a day or a few days without trouble. As a team, where we are continually encountering code we have never seen before, the impact of bad code may well hit us tomorrow morning.

I've Been Good, and I've Been Bad, and Good is Better

I’ve been programming for clean code for a long time, and as it happens, over the same interval, I’ve slacked and written code that’s not so good. I pay attention to what happens to me, and I’m sure of this:

I can feel the bad code pushing back the very next time I see it, even the next day. I can feel myself flowing through the good code with ease, even the next day but much more readily a week or two later.

For me, I’m sure good code pays off within days. Bad code hurts me within days, and sometimes hours. Your mileage might vary. Until you can do it as cleanly as, say, Bob Martin, my guess is that you are kidding yourself. I don’t know for sure what will happen to your team, but here’s how I’d bet.

Bad code will slow you down if you write it for even a few days. If you write bad code long enough to get an actual product out, you will deliver that product more slowly, and with more bugs, than if you had gone clean.