The Symptoms and Causes of Technical Debt

by

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?

  1. 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.
  2. 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.
  3. Make reduction in debt an aspect of each iteration.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|