In the development cycle there are many places where technical debt can rear its head and cause problems down the line for the product you’re developing. In order to tackle the problem of technical debt first teams need to know what it’s comprised of, how to identify it, and, then, how to address it’s presence in a system.
Technical debt is comprised of several attributes, each with its own set of ‘symptoms’ that should be signals to increasing levels of tech debt in your system.
They are:
- Implementation Debt: this manifests itself as code duplication, static tool rules violations, and code smells.
- Design and Architectural Debt: this can be seen through design smells and design rule violations.
- Test Debt: this is either when there is a lack of tests, inadequate coverage, or improper tests in the code base.
- Documentation Debt: when there is a lack of documentation, poor documentation, or documentation that is severely out of date.
The points mentioned above are tell-tale signs that there is technical debt in your code base, but there are also different types of debt that can be present. These types of debt vary in how and why your development team is incurring technical debt.
They are:
- Strategic Debt: it is incurred knowingly for strategic purposes (such as first-to-market release) and the debt is taken on in the long term (not to be paid back in the next sprint).
- Tactical Debt: is also taken on knowingly but for quick gains and is meant to be paid back in the short term.
- Inadvertent Debt: it is taken on unknowingly due to a developers lack of skill or awareness of how technical debt is incurred.
- Incremental Debt: is continuous inadvertent debt.
Looking at the breakdown of technical debt, from its symptoms to how it is caused it’s easy to see that debt is inevitable. However, in order to keep that debt from taking over your code base and slowing down developments, steps to stop this debt from accumulating need to be taken.
How do we do this?
The first step is heightening awareness around technical debt; holding team meetings where technical debt is explained (as above) and then introducing and putting into place relevant processes to address it. In order to prevent technical debt build up, development teams should hold training sessions in order to learn and, in the future, perform best practices.
Once preventive measures are put in place within a development team, the team should focus on repaying existing technical debt. When technical debt builds up in a code base it slows down development and can cause breakages and outages. Therefore, paying back tech debt needs to be a priority. But there is a paradox that needs to be resolved: it is not always feasible to stop development in order to pay back debt and letting tech debt run rampant is also not a possibility. So how do teams find the balance between maintaining continuous delivery and best practices for technical debt repayment?
- Identifying, documenting, and tracking technical debt is the first step. Without the knowing how much and where there is technical debt in the code base, a plan can’t be set up to pay it back. There are several static-code analysis tools that enable the tracking of technical debt to help this.
- Prioritize what parts of the code base need to be dealt with first. The areas most susceptible to breakages or user experience should come first.
- Make reduction in debt an aspect of each iteration.
- Incentivize team members to deal with technical debt. This will create a culture where technical debt repayment is not labor, but something that is rewarded.
- Keep an eye out for large-scale debt payments that can be fit into the development schedule and improve the overall status of the code base.
- Repay technical debt horizontally. This means not just paying back test or design debt, but recognize that all types of debt are ultimately interrelated and need to be dealt with cohesively.
- Some debt doesn’t have to repaid – this is the debt that is incurred in prototypes or products that are reaching the end of their life-cycle.
Ultimately, in order to deal with technical debt a systematic approach needs to be taken; pragmatism is also key when dealing with debt.
To read the full post visit here.
