In this short article I would like to say a few words about the phenomenon of code biodegradation and present you some tips on how to deal with it, so that your everyday work doesn’t become a real ordeal over time.
Robert C. Martin’s „Clean Code” describes phenomenon of code and software project quality biodegradation. Usually, it means that projects developed for several years are sliding into chaos, therefore further development becomes unpleasant. Adding new functionalities becomes incredibly difficult and prolongs indefinitely. Degradation is a process that occurs naturally in projects despite the use of best practices such as B/TDD, pair programming or other common practices that improve quality.
At this point, probably all of you wonder why this is happening.
To find the cause of the phenomenon we have to realize that any code, sooner or later, becomes a so-called legacy code. This is because the duration of large projects is usually longer than the work of developers who create it, and rotations in the team is natural. In extreme cases, when the project takes a long time it can lead to a situation where a team is no longer composed of people who created the application from the scratch, but only of "new" people, who have to face legacy code. As a result, such people don’t know the vision of the project creators, they make things more and more complicated without full understanding of everything. Entropy in such a project grows, which makes the code more prone to errors the longer this phenomenon occurs.
Here, you probably ask how to counteract this process.
One way of dealing with food biodegradation is freezing. When it comes to code, it can also be frozen, we should take away access to the repository and then we can be sure that no one will break anything. This solution, however, is unrealistic in the software world, because we need to develop our products, so in order to fight the evil phenomenon we have to counteract biodegradation all the time. One of the easiest ways to do this is to use the principle of scout, which is as follows: "Leave every place you visit in better shape than you found it. "In the case of code that could be used in such way - if we notice, at some point, that code can quickly degrade, we try to "leave something good behind ". Another thing you should do, is to boldly defy the principle that is followed by many people - "If something works, we don’t touch it because we can only spoil it"; instead, we should apply the principle - "If I can do something better, I do it, I don’t wait until someone tells me to do it, I just do it".
Sure, many people will tell you that it all sounds nice but in their project there is no time for doing code refactoring. In my opinion this is a poor excuse as carrying out basic improvements in the code takes little time. If we had mastered development environment, many operations would have appropriate shortcuts. Besides, we don’t have to immediately leave the code in perfect condition, it’s enough to leave it in a better shape than it used to be. Mikado Method [1] will be perfect in this case.
It is worth remembering that no one creates perfect code from the beginning, it becomes one after implementing an appropriate number of amendments.
How to implement scout principle in a project, in this case?
As a leader, you can force your team members to apply scout principle and everywhere it is possible we could repair code. However, as it happens with the injunctions, this is not the best way to teach people. It would be better to convince members of our team that this principle is good and it works. We must bear in mind one thing, developers can be divided into 3 groups:
- They don’t know how better code should look like
- They know how better code should look like, but they don’t repair it
- They know how better code should look like and they repair it
People in the first group are best to pair with someone more experienced to let them try pair programming and show how good code looks. When it comes to the third group, we have our desired goal and we don’t need to take any actions. The problem occurs with the second group, which, despite the fact that has necessary skills, is unwilling to use them in the right way. Then, what to do to create a team that consists of mainly people from the last group? To answer this question you need to consider in what way people of the second group are different from the ones in the third group. They want to do what they do in a best possible way, because they can’t afford to create bad code. If we manage to instill something similar in the rest of the team and motivate them internally, they will feel pressure that if they work with such good people they can’t afford to be outdone and to disappoint colleagues.
The problem of preventing code biodegradation from the technical side is described by a number of books, first and foremost by Robert Martin’s "Clean Code". Therefore, I won’t write about it in details but I would like to mention a few key aspects.
Since we spend much more time on reading code than writing it, it’s very important to ensure its legibility. Code created by us must be written in a way that it is readable not only for us but also for others. We try to use as few comments as possible, if the code requires them, it should be a warning for us that something is wrong. The perfect code should speak for itself and comments shouldn’t be necessary; it almost doesn’t have comments.
Another worth remembering aspect is simplicity. Code created by us should be deprived of some strange hacks or other unnecessary things that are understood only by the author. Everything that is unnecessary should be removed and code optimizations should be carried through its simplification.
The last aspect I would like to mention is testing. Unit tests should be created whenever possible and we should benefit from TDD, because it will give us the security that the changes we have introduced won’t spoil anything. The presentation, which explores the topic more broadly and on which this article was based, can be found here [2].
[1] - http://www.methodsandtools.com/archive/mikado.php
[2] - https://www.parleys.com/tutorial/514892270364bc17fc56bfc2/chapter0/about
