• Jake Brewer

What is Technical Debt?

Updated: May 14, 2019


Technical Debt, a concept in software development reflecting the implied cost of additional rework caused by choosing a quick and easy solution now as opposed to a more maintainable approach that requires more time and effort. The Software Engineering Institute at Carnegie Mellon University : “conceptualizes the trade off between the short-term benefit of rapid delivery and long-term value.” In more relatable terms: code it quick to get it out the door as opposed to evaluating and testing more efficient development methods which require less maintenance and higher user satisfaction for the long term.

Technical debt has many things in common with financial debt. Like financial debt, there are costs and benefits which relate to timing and quantity. In both cases, becoming over-leveraged can lead to huge ongoing expenses. Additionally, these debts can provide access to something sooner than is otherwise possible. But the big picture should evaluate if the extra costs are worth the immediate benefits.

While there are many similarities to financial debt, technical debt isn’t as simple as financial debt. Technical debt comes in several varieties: planned, unintentional, and unavoidable. Technical debt affects many areas including: compatibility, security, reliability, usability, efficiency, maintainability and portability. To understand the costs and benefits of technical debt, it is important to understand the different types of technical debt.

Planned Technical Debt

Planned Technical Debt is a strategic move which requires a full understanding of the risks and costs of taking on the technical debt while knowing how to reduce the debt in the future, should that option be chosen. Companies sometimes utilize technical debt when an impending deadline does not support a more complete approach or, more commonly, to prototype a concept. Planned technical debt can allow a team to release sooner at the cost of greater ongoing maintenance.

Planned technical debt, if left unchecked, can add up and end up costing the company time, money, and agility. It is important to keep a record of when and why the decisions are made and track any ongoing expenses caused by the debt, which can include increased developer hours, maintenance down-time, and lowered user satisfaction ratings.

Unintentional Technical Debt

Every business has its flaws and employees make mistakes; they are only human. Unintentional technical debt may be a result of a knowledge gap or just poor workmanship. Some causes are excessive/incomplete/inaccurate design, extra/missing/incorrect requirements, or extra/missing/incorrect coding. This is akin to a spouse or child having a secret credit card, if unnoticed and neglected, it could become a large hidden expense.

Unintentional Technical Debt is the worst kind of technical debt, because it easily escapes notice. Hiring skilled & experienced staff, accurate and effective communications, and non-punitive resolutions to mistakes are the best ways to prevent or at least reduce this type of debt.

Unavoidable Technical Debt

This type of debt occurs with software updates, regulation changes, or a shift in requirements. In order to avoid or minimize this debt, it is advised to apply updates, changes, or requirement shifts as soon as reasonable to prevent accumulation of added security risks. Using automated testing allows updates to be released with confidence.

General advice to minimize technical debt

As with any debt, measurement and tracking give clarity when making decisions. When managing technical debt, the most important thing a team can do is recognize it and define what can or cannot be done to manage it. Here are a few of the many ways to measure and manage technical debt:

  • Monitor team’s rate of progress – a slowing may indicate an increase of technical debt.

  • Requirements – monitor origination, size, change, deletion, lead time, planning time, implementation time, and related bugs.

  • Documentation – size, frequency of changes, updates, deletions. Documentation should be large enough to be useful and have little if any information of no value.

  • Monitor bugs – how often do bugs happen? How long are bugs left unaddressed before investigation? How long does it take to complete an investigation? Once the problem is identified how long does it take to fix it? Was a failing test written before the bug fix was started? Has this same bug happened before?

  • Track and maintain code test coverage – 70%-95% of code covered by well written unit tests is a healthy target range. The target should be adjusted in that range based on observations. Too high and developers could be writing more feature code, too low and more bugs will get through.

  • CI/CD pipeline – Don’t allow code into the delivery branch until automated quality controls have accepted it.

  • Automate, Automate, automate – humans are not good at repetitive tasks, automation will allow a well-documented procedure to be perfectly executed every time.

It is important to leverage and manage technical debt. A large debt will negatively impact a business. By communicating with the IT department about technical debt early on, a company will be able to reduce the rate that technical debt increases. Clarifying the point that technical debt is costly and compounds will allow that team to identify and minimize this risk. Lower technical debt results in better lead times and improved quality with the same amount of resources.

What does Technical Debt look like?

For example, a person works for an IT company and develops web applications for clients. One client requests many pages with several similar elements. The quickest way to deliver is to copy and paste some HTML for each of the pages. The debt payment happens when an update is made; the change now needs to be updated in many places. A lower debt solution would be to use a solution like React or Angular to apply these updates. These technologies create design templates. By using these templates, any changes or updates in one place will correct all the similar sections. The cost of utilizing templates require more expensive resources to develop and take more time upfront. The payoff is quicker turn around in applying changes and fewer mistakes (such as something missed on an existing page or copying and pasting errors in the HTML) which continue indefinitely.

Startups and Technical Debt

Some would argue that technical debt is unavoidable for most startups. Startups typically operate for short-term benefits, resulting in quick delivery and high debt (both financial and technical). Startups may not intend to own their work long term but rather create a proof of concept, then find a quick exit, leaving it to a more financially capable buyer to address the debt.

Prior to acquiring technical debt, it is important to know the return from taking on the technical debt. Technical debt is used with a short-term goal in mind, and low technical debt when a longer-term goal is the target.

Technical Debt is neither bad nor good, if there is an understanding to the use and when to address the debt (if ever). Acquiring technical debt may help to achieve a short-term goal. If there is concern about the long-term functionality, production errors, or a slow rate of change, technical debt should be minimized.

At IT Efficiency Consulting we are passionate about making your development teams more effective. Ask us how lower technical debt can improve team morale, productivity, and quality all at the same time! To learn more about how/when to leverage technical debt, track the impact of technical debt on your projects, measure the amount of technical debt in your systems, or how to reduce technical debt:

Contact Us

40 views0 comments