Why not write clean code?

I think you already know what clean code is: this is the famous Uncle Bob book, which provides a very accurate definition of readable code. Ever since that book was published there have been a lot of talking about Clean Code. People talk about craftsmanship, readability. They even go to code retreats. Should you say something publicly against clean code you’ll find yourself on a "never to be hired" list. Talking about Duct-Tape Programmers is not cool anymore. Even Dave Paul Graham agrees that we have to write re-readable code. OK, maybe Paul said that years before Uncle Bob published this book, but you get the point.

Sadly, nobody asks why not write clean code? I have many independent reasons for that:

1. Any fool can point out mistakes in clean code.

Suppose you spent some time and effort on making your code clean. You removed duplications, you used short and consistent names, your methods are easy to understand. At a certain point you decided that this much polishing is enough – shipment is a feature anyway.

Some time later a colleague will look at your code and point out actual problems. The more names you use the more you can misspell. The shorter methods you use the more easy it is to find duplication. So your coworker walks over and tells you how to improve it. Shame, isn’t it?

None of this could have happened if you wrote messy code. In that case the best your coworker could say is “it’s dirty”. There is a good reply for that: “So what? It works! The louder you say that the more convincing it is. Nobody would find bugs in your code just by looking at it.

2. You like to be important

Suppose you go to a vacation for 2-3 weeks. When you come back your colleagues tell you that a user reported a bug in your code – and they fixed it. They’ll tell you that they factored out a few things without introducing new bugs , thanks to your thorough unit tests. After that refactor, they would say, they could easily fix the original bug and release the new version.

Something doesn’t feel right, does it? It sounds like you are replaceable – and now everybody knows it. It should never happen. Wouldn’t it be better if they called you in the middle of your vacation to fix that thing ASAP? It’s a little inconvenient at first, but who cares? Your family will know that you are a super-important world-class hacker. Your coworkers will know too that if you leave, they can rewrite your module from scratch.

So what to do when they call you with an urgent problem? You have many options:

You can kindly explain that it’s a very easy problem and you can tell them how to fix it. If that method didn’t work out well you can still blame them for misinterpreting what you said
Quite often you’ll get your hands dirty and fix the problem yourself
Sometimes you can be a little harsh, e.g. “Can you guys get done anything without me?”
Bottom line: everybody will treat you with utter respect.

3. You don’t like OO principles

There are these acronyms like DRY or DIP. If you google them you’ll find long explanations about, basically, nothing. All they are saying that for some abstract reasons like flexibility or modularity you’ll have to write more complex code. Once you start paying attention to these principles your code will be full of Design Patterns.

Come on! Do you let these principles diminish your effort to patternless code? You know you can do better! You can say that all those patterns add unnecessary complexity to your code. Should anyone question why you have 7 almost identical variations of a code block across 3 methods you can always tell them: “this way you can easily see the flow: one step after another”. The more often you say this the more convincing it is.

4. You want to create jobs for others

I know you are a true altruist deep down inside. Once you write that service you don’t want the company founders to take all the money. You want them to hire more testers and software engineers to understand and maintain the thing you created. What can be more noble than creating jobs and puzzles for other people?

Are there any real reasons for not writing clean code?

OK, let’s put the jokes aside. Are there any reasons for not writing clean code? Well, one could ask if are there any reasons for writing bad code. That’s a big no-no. However, the cleanliness of code is rather a 0-1 scale than a 0/1 boolean. I believe there are a few cases when you don’t need to write extra-clean code:

1. You don’t know how to write clean code

Indeed this is a real one. Say you want to learn how to write clean code. You are really enthusiastic, however, you tend to take everything literally. (I am also guilty of this.) Well, then, you shouldn’t write clean code right away. If you try to apply all the techniques in that book then you’ll end up with the worst code you ever wrote. I suggest to learn and practice them one by one. Once you can apply a technique almost automatically then you can go on to the next. Sooner than you think you’ll write amazing code.

2. You are in crunch mode

This is real too. Sometimes you are in crunch mode. Maybe there is a bug in your service and your company is loosing hundred thousand dollars each day until it’s fixed.

I’m hesitating to mention the case when you work for a startup, having to release something before your competition does. I’m hesitating because you can save most of the time on choosing RAD tools. You can save some time (and gain a lot of bugs) for not using TDD (more on this here). Although it is clear that startups cannot spend time on extra-clean code, writing bad code won’t help either.

For whatever reason you are in crunch mode: Go ahead, fix and ship for the greater good. Just don’t forget to clean up the mess later.

Originally appeared at tamasrev blog.