DEV Community

Tamas Rev
Tamas Rev

Posted on

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.

Top comments (8)

Collapse
 
justgage profile image
Gage

I work at a sort of start-up. We're pretty successful now so it's a little less about"move fast and break things" however I find that many times the reason to not write clean code or fix some is because it's too expensive to do so and the code doesn't matter that much. Many times if I want to do something the less clean way it'll take 1 day, however if I spend the time to make it awesome it'll take a week. That's a 5x increase in cost! Sometimes I've realized that I'm essentially polishing under the toilet in a cruise liner were no one will see, and even if they did they'll wonder why they didn't focus on the rest of the more important pieces. Sometimes it makes sense to polish, other times it's something that is very utilitarian and "just has to work". The business doesn't have the money or the time to have every piece of the ship polished, just the were it counts.

Collapse
 
tamasrev profile image
Tamas Rev

It's programming, so the answer is always "it depends".

Writing clean code is difficult in the beginning. Later it'll be natural. Say for instance, I don't write long methods anymore. If I do, then I can always click on Extract Method refactoring in my IDE.

Anyway, business is important. We always need to balance between up-front and maintenance costs.

Collapse
 
justgage profile image
Gage

Sorry, to be fair. I think perhaps the definition of "Clean Code" is causing us problems. I think if "Clean Code" means well-architected code that has a lot of upfront design, then this can be problematic. Especially because all that upfront design can be wasted when a new unexpected requirement comes along. However, if clean code means you modularize as things grow and become harder to grok, I think this is always a good practice and really doesn't require much time. Admittedly I often have had the problem in the past of looking beyond the goal and gold-plating things or making unneeded changes that were breaking changes because they felt cleaner. Often they weren't an improvement and at worst they introduced new bugs.

Overall I'm a huge fan of clean code.

Sorry if my comments came across too combatively.

Thread Thread
 
tamasrev profile image
Tamas Rev

Your comment makes sense, totally. I don't think it was combative at all.

In the Working Effectively with Legacy Code, Michael Feathers wrote that programming requires good judgement. So I can't tell you from my seat how much polishing is enough for you. I don't know what kind of environment are you working in. I don't know if your employer can tolerate little more polishing in order to reduce maintenance costs. I don't know if you're working on an experimental feature.

We need to consider these, when we decide how much we should polish our code. Probably there are other aspects too.

So, in general: we should write clean code. In particular: it depends ;)

Collapse
 
jstvssr profile image
Joost Visser

Nice perspective! For those that do not know how to get started on writing clean code (or get their team to do so), check out the Better Code Hub on the GitHub marketplace and the accompanying O'Reilly book Building Maintainable Software for some truly pragmatic guidelines. For full disclosure: I am one of the authors. Happy to share some free copies with educators or startups.

Collapse
 
tamasrev profile image
Tamas Rev

Thanks, I'll check it out.

Collapse
 
arne_mertz profile image
Arne Mertz

Nice article!
Joke #3 has some truth to it. Too many devs add a design pattern and complicate things although it's not needed. The justification usually is "it's in the GoF book, so it must be good!"
The result can be a code base containing literally hundreds of singletons (been there...)
Another reason to write not-so-clean code is writing prototypes, spikes and other throwaway code.
I'm on the way to give a 3-day course on clean code right now - if I may I'll insert one or two of the points inn this article.

Collapse
 
tamasrev profile image
Tamas Rev

Yes, sure, you can use these points :)