Where it all ends.
In order to know when you are at the end of something, you need to know where it all began. Technical debt is something that none of us will manage to avoid every time we code. Most developers write messy code sometimes. It may be because they don’t know how to write clean code, or circumstances might force them to introduce shortcuts. The only way to avoid technical debt in a project is to resist the urge to add more code and we all know that this is not always possible. It’s like moving to a new house and not living in it because you are afraid of creating a mess. You’re bound to make a mess and have to put time aside to tidy up. A considerable amount of time for some of us. The longer you postpone cleaning, the bigger the mess. Ignoring technical debt will have a direct impact on the time and effort required to maintain and eliminate the debt.
I hate the very idea of cleaning so I guess my approach to it isn’t exactly reasonable. I start by focusing on a small area of a room and if I come across something that isn’t supposed to be there I put it to one side. Having tidied that area, I pick a new area to clean and repeat the process. I usually start in the corners and this of course leads to a stupendous amount of clutter piled in the middle of the room which tells me that it’s time for a well deserved break.
It’s not the greatest cleaning technique, I admit. If I approached the problem with prudence and forethought I could have anticipated the result. Had I put away the stuff as I picked it up, I could easily have avoided this unmanageable heap in the middle of the room.
Just like cleaning a room, cleaning code must be done with care, ensuring that any changes that we make won’t have a negative impact on the rest of the code. This means one thing: TESTING!
The incorporation of unit testing into your work will ensure that any changes of code can easily be tested to detect whether something has gone wrong. But testing is a whole chapter by itself, something I highly recommend looking into.
It is easy to see when it is time to tidy up your room. Knowing when to clean your code is just as simple. When a small task like changing the background colour of a page takes a long time, then there is something wrong with your code. There are several reasons why things can go wrong due to minor edits of code, such as:
1- Having to repeat lines of code in several places;
2- The change requires more code than initially anticipated due to tight dependencies;
3- Being unable to determine where the change needs to be added in the code.
Working with messy code just means that you create more messy code. You may feel that you do not have the luxury of taking more time to clean up your code but this does not mean that you can (or should!) ignore the mess. At the very least, you are expected to add “TODO” comments in your code, explaining how the code can be improved. These comments are nothing but a reminder of the mess. However, this isn’t an open invitation to drown the code with “TODO” comments. The idea is to eventually get stuck in and resolve them. Spring cleaning, anyone?
Keeping a room clean is a process of putting everything away in the right place. Dirty clothes go in the washing basket. Jackets and scarves need to be hung up and shoes go underneath… You get the idea. Cleaning code should be done in the same way: as a process done at the same time as you add new code. When a function becomes too complex, break it down. Instead of adding new code on top of messy code, write your code neatly. This will force you to simplify the depending code blocks. At times, you will even find yourself cleaning the mess surrounding your beautiful code.
We might think we have found the perfect start to a project that will avoid technical debt, but this cannot be guaranteed until any code is written. New code will depend on the foundation of the source code. If this is not done correctly, if the initial commit is rushed, it will show in every new line that is added. Make it a habit always to stick to coding standards and the result will be consistent source code. Failure to keep to these standards will have a negative impact on what is acceptable as good code.
Don’t shy away from the thought of holding code reviews. These reviews will be beneficial to the developer who reviews the code, and to the developer whose code is being reviewed. It allows for an open discussion of why the code is written as it is. Has the developer found a way to improve the coding standards? Or perhaps the standards weren’t fully understood and need to be explained? So, now do you think that you have found the perfect start?
You know that you have failed to maintain technical debt when code becomes unmanageable. Besides testing – and I can’t stress how important testing is – it’s important to review the source code from time to time. As you add new lines of clean code, make sure that it doesn’t impact the existing code negatively. Don’t ignore a mess and don’t you dare make one!
