Technical Debt and Risk: One and the Same

by

Technical debt is a very important concept to developers that is often lost on the management end. Developers use the concept to describe the consequences of a pressure to meet deadlines; to release features on time developers will write quick and dirty code, compromise on standards, and leave code quality out to dry. Technical debt is the choice between making sustainable software and making short-term decisions that are detrimental to code in the long run.

For management, debt wouldn't be the term they'd use to describe the concept - but they would rather see it as the risk of increasing costs or missed deployment schedules due to the current development process. Any code written has inherent risk associated with it. Therefore, technical debt is not seen as something ineffectual, but as, sometimes, a necessary risk. To be able to decide whether the risk is acceptable or not technical debt has to be quantified.

There are several ways to measure the presence of technical debt in a code base:

  • Estimate Accuracy: without technical debt the estimations of time needed to develop a certain feature would become more accurate overtime. As developer knowledge in a certain area increases (knowledge on tools and frameworks, team performance, etc) estimations by developers would become more accurate. If this is not happening (and estimations become less accurate and more difficult to pinpoint) it is likely that the system is plagued with technical debt. The decreasing accuracy of estimates can be measured and, therefore, be used to measure technical debt.
  • Time to First Feature: the time for adaption by new hires is a useful metric for technical debt. This encompasses the comprehensibility of the code and the developer's own ability to understand the code. Both of these components are important, but if it has become typical that new hires need more time to bring components into production "it is likely that that the learning curve has become too flat". Technical debt is often the cause of this.
  • Internal Metrics Failures: developers and devops often use tools and metrics to see if code is meeting certain standards. It is likely that your development team already has an internal tool in place to track that status of software; it can be the case that this tool indicates poor behaviour most of the time, and that can be normal. But also keep in mind, that if you have a component that has been marked for 30 days as performing below satisfactory, there's probably technical debt present. The duration of failure to meet standards is a key indicator technical debt.

So once you've measured the presence of technical debt in your system, how do you manage it?

Technical debt is often seen as solely a negative thing, but just as we mentioned that risk is inherent to code - technical debt is also inherent to a system. Many teams immediately fight against technical debt, even before it has actually shown itself to be present. Other teams entirely ignore technical debt, mounting pressure on their developers and digging themselves into a deeper debt.

Ultimately, it is necessary to know how much debt you are incurring. This means either documenting debt in the moment, or when it starts showing itself in the system. The latter option is perhaps the better one, as it automatically helps prioritize those debts that need to be addressed first.

Once you know where and how much debt you have, repaying it from time to time is important. It is best to repay it sooner rather than later, because the longer they are in a system the harder it is to identify. Refactoring is the best way to go about this. This means that there will probably always be certain levels of technical debt present in your system, which means certain levels of risk, so preparing for possible failures with a contingency plan is also a good idea.

Dealing with technical debt is dealing with risk. In a business you can't be risk-averse, but deal with it smartly. If you deal with technical debt in the ways mentioned above, you system should be safe from any from any major problems and enable business growth.

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

|