The accumulation of technical debt is a cost driver in advanced projects. Here are some tips to reduce them
Technical debt is a metaphor commonly used in computer science for the possible consequences of poor technical implementation of software.
As for poor software design, the impact of accumulated technical debt is the same as Martin Fowler describes in “Design Stamina Hypothesis.”
In short sentences, the result is that the time to implement new functionality increases. And it becomes harder to add functionality. Consequences are more effort, more costs, increased system instability, more crashes, more bugs, complexity, etc.
The most important thing to reduce technical debt is the regular refactoring of your software.
Roughly speaking, the software development process consists of two steps:
1. meet the requirements and get the software running
2. Optimize and clean up the code
In many projects, the timelines are met with fulfilling point 1. For point 2, optimizing and cleaning up the code is often no time. The result is that after a few years, the software systems of these projects are only difficult to maintain.
In modern Scrum projects, the issue is that a Scrum Master often focuses on the delivery of new functionality.
If your Scrum Master sees reducing technical debt and/or refactoring time as technical stuff not relevant to product owners, then you are really in trouble.
The same applies when your product owner thinks this is technical stuff and is not interested in refactoring results.
One possibility is to measure the improvements of refactoring. This can be in reduced lines of code, improvements in response times of your application, fewer bugs, and fewer escalation meetings.
As well it could result in lower infrastructure costs. In the end, most optimizations should be measurable in money.
For refactoring, you can also use tools that show possible improvement areas. One possible tool to show improvement possibilities is SonarQube.
Using software analyzing tools
Today there are many tools to analyze the quality of code. One good possibility is to include these tools in your delivery pipeline and let it run for every change.
The advanced level is that the tools are used by your developers on their local workstations, and the checks are done by every save of a change. The reason is that the sooner a quality problem is noticed, the cheaper it is to fix it.
There are different areas for scanning by tools:
Linting is important to reduce errors and improve the overall quality of your code. Using lint tools can help you accelerate development and reduce costs by producing to have clean code. If the code is clean, the risk of bugs is reduced.
Code linters are also available for Dockerfiles, configuration files, etc.
SonarQube is one option, and you can add it to your pipeline as well. SonarQube is also supported by integration tools like GitLab.
Recommended is to check the packages you use and the dependencies. Often versions need to be replaced with updates to fix newly found security issues. Different tools are available, like Mend, formerly WhiteSource, Fortifyor Open Source Security Management Snyk.
There are plenty of other scanners. Maybe you know better ones.
Some platforms offer functionality to verify the quality of your code based on the specific language. Like npm audit for Node.js or Java tools like JArchitect. As well, for Python, several static code analysis tools are available.
A helpful way to prove the quality of your software system is to ask others for a review and their opinion. Exchange and communication lead to learning and improvements.
One easy way is code reviews. The issue with code reviews of peers is often a lack of time and understanding of how to do an effective code review. For newbies, a list of important points to look into can be helpful.
You can add to your team one advanced developer with the main function of doing reviews. That could improve the quality.
You can ask another team for a review if you work in a company with more teams and developers. Some big companies have specialized teams for reviews and audits.
An external audit can be extremely eye-opening if it is worth it for your management. Usually, the external audit team needs support from your development team members.
The process is that they explain the system and provide code. The audit specialized company often has more developed analysis software. Additionally, there are interviews of the developer team members.
The result is a report of the quality status of your software system and areas of improvement, plus the presentation of the results to the developer team with a list of hints for improvements.
The use of software patterns usually reduces technical debt.
For example, the use of the Model-view-presenter (MVP) pattern. This pattern benefits modularity, testability, and a clean and maintainable codebase.
There are tons of clean code patterns. Here are a few ideas:
If you want more, you can look into the SOLID principles for clean code.
As you can see from the previous chapter, the number of patterns and principles is enormous. It is nearly impossible for a developer team to find on its own a focus on the most relevant patterns and principles to develop and improve a specific software system.
Help can be provided for the developer’s team with tailor-made guidelines for the specific development project.
Developer guidelines should be as short as possible and be focused on the main aspects. That could be which principles and patterns are relevant for the specific project, like:
- code conventions, naming conventions
- test-driven development and how to handle exceptions
- language for comments, classes, etc.
- rules for standard commit messages
- code quality scanners for your software systems and their configuration
- use of pair programming
- and much more
If you like to have some ideas about what could be part of developer guidelines, you can find some hints here:
Using architecture principles can help reduce technical debt because it gives developer teams, from a high-level perspective, general rules and guidelines for using IT resources.
One example of a software architecture principle is the API first principle which results in a design that one software system can be more easily integrated into other software systems. The result is flexibility. The technical impact is that the design needs to be adopted to provide APIs.
Another principle is to reduce complexity. Complexity can be found in software design, providing functionality and used infrastructure. Complexity can also be reduced by clean code. Refactoring to reduce complexity results in an easier run of the system in production with fewer problems.