The concept is simple: due to a lack of resources, people sometimes do not address a problem correctly when shipping a new feature or fixing a bug. This debt must be repaid (e.g. the problem needs to be addressed correctly) or the debt will accumulate and impact the software development in the future.
Definition
Technical debt is a term originally coined by Ward Cunningham, a metaphor that applies financial rules to the technical world. The concept is simple: due to a lack of resources, people sometimes do not address a problem correctly when shipping a new feature or fixing a bug. This debt must be repaid (e.g. the problem needs to be addressed correctly) or the debt will accumulate and impact the software development in the future.
There are many sources of technical debt: code smell, code duplication, complex functions, readability, lack of documentation. On top of the technical aspect, the organizational aspect of the development team is also very important (as stated in a recent article referencing two papers about bug prediction at Microsoft).
Impact of Technical Debt
Unfortunately, as software is becoming ubiquitous, we are seeing the impact of technical debt every day. All objects you currently use (phone, washing machine, fridge, car) rely on software and have some technical debt.
When your camera, router or device is being hacked because of undetected buffer overflow, unhandled firmware bug or even more simple, outdated dependencies. It not only impacts you directly. And it also costs a lot of money and loss of reputation to the manufacturer (lose of trust, potential lawsuits, etc.).
When your car is being hacked or accelerate unexpectedly, when your plane is having issues. Even when there are stringent regulations, technical debt is present and affect critical systems.
Writing software to deliver a product is relatively easy. Maintaining it for years, delivering new features while maintaining the existing ones is extremely hard. In some cases (avionics, aerospace, nuclear power plants), engineers maintaining the system were not even born when the system was written. How to keep control of the potential debt that will be added in between?
Why do we need to address it today?
In 2011, Gartner estimated the cost of technical debt to $1 Trillion in 2015. We passed the limit and technical debt keeps accumulating. Some estimates the cost of technical debt to more than $2.84 Trillion. Many tech companies realizes the importance of addressing technical debt early to avoid technical bankruptcy and are now dedicating roughly 10% of engineering time to address it.
With more than 23M developers in the world today (and with many more engineers to come in the next years), we need to improve the software engineering discipline and have better processes to avoid technical debt and produce better code from the start. Otherwise, we are doomed to produce software that will start to fall apart few months after its delivery.
Measure your Technical Debt
How to measure your technical debt and start to take action today? There is a way.
I started a company called Codiga that develops a platform to help developers and managers delivering better quality code. The platform measures technical debt and provides insights as to how to reduce it.
The analysis engine exposes the health of your code base through one metric: the Code Quality Score. The Code Quality Score is a simple metric derived from metrics aggregation that indicates how good is your code base. The picture below shows how Code Inspector surfaces that value.
Getting your Code Quality Score is a first step in addressing your technical debt. Once you have it, you can understand the major issues and establish a plan to address them.
The platform also provides visualization of historical values of your code quality so that you can keep track of your project health over time.
Develop Processes
Getting the current quality metric is just the first step. The next step is to guarantee no more technical debt is being added every day. To do so, we must add technical debt detection to every potential code change. This is done in two ways:
1. add checks in your continuous integration pipeline and configures it so that any code change with any violation, duplicate of complex code is rejected. That way, you ensure that new code is not adding new problems.
2. use automated code review: let's static analyzer review and annotate new code written by developers before it is merged into the main branch. That will catch the errors at the time of review and will (1) ask developers to address these issues and (2) spread good coding practices in your development teams.
Code Inspector supports both ways mentioned above: you can add it to your continuous integration pipeline and have the engine analyze and annotate every code change. It is currently integrated with popular development platform such as GitHub, Gitlab and Bitbucket.
Wrapping up
As our society continues to grow its use of technology, technical debt will continue to negatively impact products we develop or use. As for financial debt, avoiding technical debt requires processes and discipline. We need tools to measure and monitor your debt to guarantee we do not declare ourselves in a technical bankruptcy.
Hopefully, there are tools to help you evaluate and repay your technical debt. Codiga is a major tool that helps you quantify your technical debt and integrates with your development environment to avoid adding more debt in your code base.
(Disclaimer: The Author is The Founder at Codiga)