Another topic that has peaked my interest recently and I have started to pay particularly close attention to as I started to really work hard and ensure that I am following best programming practices and reduce any introduction of “code smell” into any code repository that I contribute to, is how to reduce the amount of technical debt a project’s code repository has and to not further increase said debt (sometimes this is not an easy task).
What exactly though is “technical debt”? The definition that Technopedia provides sums it up pretty good in my opinion .
“Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”
Some of the causes of technical debt that Wikipedia also provides are also very good and I have worked on projects that have code base’s with technical debt that range from extremely high to very little. Below are several that I personally feel are major contributors when working on projects of any size :
- Insufficient front up design (just take the extra time to think about the implementation, it will help in the long run)
- Business pressures (unavoidable, especially when you have obligations to meet, etc.)
- Tightly coupled components (most likely the cause of bad design to begin with, so design and plan ahead first)
- Lack of a test suite (all too common in most code repositories, test driven development not utilized or unit and integration test harnesses are missing entirely)
- Lack of documentation (again, all too common; not enough time to write up the necessary documentation to not only help you at a later stage but others working on the project too)
- Lack of alignment to standards (sometimes developers feel the need to re-invent the wheel and re-write already publically available libraries, frameworks and APIs causing a major headache down the line)
Now that we have highlighted what technical debt is and some of the causes, it is just as important to try and reduce this technical debt over the lifetime of the project. However sometimes this is just not possible due to a number of uncontrollable factors. Other times however it is squarely in the developer’s hands to reduce as much technical debt as possible while not increasing it as bug fixes, features and improvements are added.
One way that has really helped me is with the use of third party tools and plugins. On most repositories that I work on now, to limit the introduction of “code smell” and ensuring that the technical debt is not increasing, the Git repositories have SonarQube  installed on them. Not only does it highlight bad programming practices when there are merge requests but it also analyses the health of the code repository. So there is now no excuse when someone merges in poorly written code when there is an external and impartial tool also looking at the merge request and not just the assignee/assignees who will merge the code; humans can miss some of the obvious things, machines with the correct setup can spot the faults instantly.
Along with the Git code repository monitored, I use a plugin called SonarLint  for IntelliJ that highlights poor programming practice and bad code before you even submit your merge request. With the use of this tool, not only does it ensure that I do not contribute to the technical debt, but it encourages me to design, plan and think what I am implementing. Before I was using the plugin, I generally thought that I was writing some good code. However when I started using the plugin it kept flagging my code and letting me know that it was not good code (slightly depressing really); but it taught me that there is still so much more I need to learn to ensure that I write good code. Now that I have been using it for a little while now, I have been getting flagged less and less (so that’s good to know that I am learning and getting better at writing clean code).
Another way that I try and ensure that the technical debt is reduced is whenever I submit a merge request to resolve a bug, or implement a new feature; I try and ensure that the class, method or module that I worked on is in a much better shape than when I found it. Sometimes it will involve doing some light refactoring, other times it will involve re-writing a small chunk of the class or method. However I only ever do this if I know exactly what I am doing, and have experience with the class, method or module. I never try and do this on code that I have very little experience with or don’t know what exactly the code is supposed to do because I could end up leaving the project in an even worse state. People I have talked to about this practice fall into several camps:
- If you are not directly working on that component don’t touch it. Just do your part and that’s it.
- Why are you refactoring something if you don’t need to? Leave it someone else will refactor or fix it later.
- Good show of initiative and desire to clean up the repository, I might end up doing the same. Every little bit helps.
The fantastic thing I have seen is that there are far more developers in camp 3 than in camps 1 and 2. I can see where developers from camp 1 are coming from; making changes to code that directly does not impact your change could pose a great risk, but if you know what it is doing and how to clean up or optimize the code, then why not try and make the repository a little better for all? If there is a TODO or FIX ME comment, then why not fix it while you’re poking around anyway? Camp 2 to me seemed a little odd. Why wait for someone else to fix something if you are already in there fixing or adding something anyway? Could this just be a lazy developer doing the bare minimum? Perhaps. Camp 2 had the least amount of people in it, but I was surprised that was even a response from some developers.
What camp do you fall in? Is there another camp out there? Let me know some of the techniques you use to reduce the technical debt and limit the amount of “code smell”.
 – https://www.techopedia.com/definition/27913/technical-debt
 – https://en.wikipedia.org/wiki/Technical_debt
 – https://www.sonarqube.org/
 – http://www.sonarlint.org/intellij/index.html