The Evil of Messy Code that Kills you Slowly
By: Fahmi Nurfikri
Tags: Software Development, Clean Code, Programming, Software Architecture

I don’t care if the code messy or not, if it works, then we’re good

Maybe we often have a principle like that, especially just before the deadline. Often we just focus on how to make a code work, without realizing what the big problem is behind it.

If we are just at the start of the project or in our first releases, we probably won’t have any significant problems. This problem may only arise when we are in the next releases. If you’ve been a programmer for more than 3 or 4 years, you know what it feels like to be slowed down significantly due to messy code being done by other people.

So without realizing it, sometimes we spend more time tidying up the previous code, rather than adding new features.

So, why is this happening?

Let’s take a look at this developers familiar lie:

We can clean it up later, we just have to get to market first!

I got this sentence from Robert C. Martin (Uncle Bob)’s Clean Architecture. Sometimes we realize that our code is messy, we are just wrong to prioritize which one is more important. Of course, the code is never taken care of, because market pressures never subside.

By choosing the market as a priority, now you have a competitor behind you, and you have to stay ahead by running as fast as you can. And that will keep you from coming back to do the cleanup because you have to complete the next feature, and the next, and the next, and the next.

You’ll never fix it, and it will live on forever

Most organizations or companies do not value refactoring and slow down the speed when needed. The only way you come back is when you are about to add a new feature and you realize that the feature cannot be added unless you change the previous code, and sometimes that keeps other functions from working.

But, what makes it dangerous?

From some of the things mentioned above, maybe we don’t see where is the danger of messy code. Let’s look at the following illustration.

Comparison of growth in engineer staff and productivity levels — Note: This figure is for illustration only (not original data). Inspired by Jason Gorman at Presentation SPA2011. You can view the full slide at this link.

From the illustration above, we can see a growth comparison between the number of engineering staff and the level of productivity as measured by the number of lines of code. If we only look at the growth of its engineering staff, maybe we can assume that the company is increasing very rapidly, because it is marked by the recruitment of many employees.

However, if we look at the productivity chart, even though the number of employees is increasing, the growth is only slightly, not even bigger than the previous release.

From there, we can see signs of chaos. When what the programmer does is concerned with output and cleanliness of code or design structure, it is not a top priority. Then we’ll see a bad ending.

If we have seen from the developer side, then here we will look from the executive side.

Monthly payroll growth from release to release — Note: This figure is for illustration only (not original data). Inspired by Jason Gorman at Presentation SPA2011. You can view the full slide at this link.

The more employees, of course, the more costs that must be spent. If you look at the three existing charts, with such growth. It doesn’t matter how profitable the company might be at the moment. With such growth, it will drain the profit from the business model and drive the company into a stall, if not into a downright collapse.

So, what’s the problem?

Uncle Bob, in his book, says every software system provides two different values ​​to the stakeholders: behavior and structure. And the software developers are responsible for ensuring that both those values ​​remain high. The problem is that they often focus on one and forget about the other.

Often we assume, when the program we are working on is working and in accordance with the requirements, then our work is finished. And therein lies the mistake.

The word “software” is a compound word composed of “soft” and “ware”. The word “ware” means the product, and “soft” means easy to change. If we want a machine that is hard to change then we call it hardware.

Let’s assume that we will build a house. Where we will build the house gradually. At the initial stage, we will build a simple one-story house. In the second stage, we will create a garage. And the third stage, we will upgrade the house to a two-story house.

If we observe this illustration, of course, we need to design the architecture of the house that we are going to make first. We definitely don’t want to, have to first destroy parts of the house to add to our garage. Or you have to destroy the house that we have made to add floors because the basic foundation is not strong enough. In addition to wasting time, we also have to spend much greater costs and much greater effort.

Likewise with software development. In making software, we must ensure that the software can be extended without having to make changes from the previous stage.

But we still have a problem

If we ask business managers, they will surely say that it is more important for the software system to work, and developers often go along with this attitude.

But we are not a business manager, we are developers. Our job is not just to make sure a program can run well. But also build a good code structure.

I love the simple logic from the book.