How a Software System Becomes a Mess

We Are Followers

One of my observations is that most of the people in this world are followers. Following others is our innate nature. Children learn to speak following their parents and people around them. People follow their religions blindly only because their ancestors followed them, without raising any question. (I am not against religion. Just mentioned this to justify my observation]

Probably this feature came to us from our ancestors as a result of evolution.  When we do something new, follow a new path, there is always possibility that we will make mistakes, choose a wrong path (that's why whenever I do something new, I know that this might bring something bad to me). Our ancestors probably followed others, because following others is usually the safer than doing something new. So, following others would keep them safe, that's why they developed this nature.

Note that nothing is wrong with following others. Why shouldn't we follow if it keeps us safe?

We programmers are also people. So, most of us are also followers. Following existing code is usually safer option for us and saves much of the effort. Then why not to follow?

How Following Might Lead to Mess?

For a moment let's imagine we can measure the amount of the messiness of a software system. Suppose initially the amount of messiness of our system is 100 units.

Now a new feature comes in. As we love to follow, we usually look at the current system and try to find some similar feature and follow its implementation. For example, suppose in our new we feature we need to display some data in a table and users will be able to change the order of the rows using drag and drop. So, we might look for any existing table that supports drag-dropping and follow it -- we might copy, paste and edit the existing code and add some new code.

As the existing code is also part of the messy system, it might also be messy. Suppose, the messiness of this existing code is 10 units. The newly added code might also be messy. Suppose the messiness of the new code is 5 units. So, after implementing the feature, total amount of messiness added to the system is 10 + 5 = 15 and the total messiness of the system becomes 100 + 15 = 115.

Features keep coming and the system keep getting messier and messier over time. So, the messiness fo the system increases exponentially over time.

How to Prevent Mess?

Let's get back to the previous example. Ideally, we want the messiness of the system to be always zero, that is not mess in the system (I know it's almost impossible, but nothing is wrong if we just use our imagination. This imagination will help understand the real world case). Always means the initial messiness of our system should also be 0.

Suppose, we could somehow make the initial messiness of our system zero. Now a new feature comes in. As usual we will look for  some similar feature and try to follow it (=copy, paste and edit), assuming there is already a similar feature. As the messiness of our system is 0, the messiness of this similar feature should also be 0. Now we add some new code (or edit it). Let's say the messiness of this newly added code is x. So, the total messiness of the system is 0 + (0+x) = x. To make total messiness 0 even after adding the new feature, x must be 0. That means the new code must also be a mess, otherwise the messiness of the whole system will increase.The similar is true if we need to write the feature from scratch.

Note that programmers will learn seeing the code of the system. So, if the initial messiness is 0, there is high probability that x will also be zero as the programmer will learn to write clean code seeing the current code base.

If we can maintain x to be 0, we can ensure that the messiness of the system is always 0. That means the system will always be clean.

Lessons learnt:

• Initial condition of a software system is very important. If we can make the initial system clean, there is higher probability that the software system will remain clean for a long period of time. So, we should try our best to design a clean system. A clean
• We need to teach our programmers to clean code, so that the new code written becomes also clean. We can also review code to ensure that the new code is clean.

[Clean code: I am talking about writing clean code. So, what is meant by "clean code"? which code is clean? In short, clean code means code that can easily be understood just by seeing the code. This term is probably introduced by Robert Martin. So, we should write code that can be understood easily. There are many benefits of writing clean code.

Clean design: roughly speaking, a clean design is a design that can be understood and changed easily. Our requirements are ever changing. So, it's wise to design a system that expects changes.]

What if My System is Already a Mess

If a system is messy, it's not feasible to make the system clean in one sitting, we need time to gradually clean it up. We can follow Boy Scout Rule:

Leave your code better than you found it.

That means when we write new code we will try to make the related old code a little bit cleaner.

Let's go back to our previous example. Suppose, the messiness of our initial system is 1000. Now a new feature comes in. In stead of blindly following previous similar features, we write clean code for this new feature, as a result the messiness of the new code is 0. Then following the rule, we try to make related previous code cleaner. Say this cleaning process reduces the messiness by 20 units. So, the total messiness after implementing the feature = 1000 + 0 - 20 = 980 which is less than what we found before implementing the feature. In this way, the messiness of a feature will reduce over time.