The Impact of Technical Debt


Back in 2017, I was asked to speak at a conference in the Salt Lake City, Utah area on the topic of Technical Debt. This is an update to the original presentation that was given.

What is Technical Debt?

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.​

Who creates Technical Debt?

Business Stakeholders (Upstream)​

How does Technical Debt get created?

Technical debt is a byproduct of making decisions​. Teams have meetings, conversations happen, and decisions are made. The goal is to capture as much of that information as possible, but in reality, it is very difficult. This knowledge is the root of all Technical Debt.

How to prioritize Technical Debt

Technical debt should be reviewed periodically to ensure it is not getting out of control​.

  • At the minimum, it should be reviewed Quarterly by all stakeholders, not only engineering
  • When system failure is in the near future, not far future​. For example, the current system design is near capacity and is preventing system growth.
  • When product cycles allow for more open development cycles. Maybe your company has a code freeze during major sales times, take advantage of the spare development cycles.
  • When new members join a team, assign them debt problems with senior staff members​. This is a great way to solve the technical debt, as you get fresh perspectives combined with a seasoned staff member.

How does Technical Debt fit into the Development Cycle

One thing for certain is that if Technical Debt is left unchecked, the entire business model is at risk of failure. It is important to find a way that will help the teams stay on top of Technical Debt.

  • Every 3 sprints, take a technology sprint to catch​
  • 80% of tasks go to business, 20% go to technical debt​
  • Create a team that deals with nothing but technical debt​
  • Catalog technical debt that was generated during the sprint​
  • Elevate risk to future development: Low, Medium, High​
  • Elevate whether to have Technical Debt prioritized in upcoming sprints.

Sources of Technical Debt

There are many sources of Technical Debt, here are some of the more common:

  • New tools that go from prototype to production​
  • Software code that lacks any design patterns
  • Software without source control (very painful)
  • Manually configured machines — best to automate configuration​ (DevOps kind of work)
  • Stale codebase — longer untouched, the worse​ it gets
  • Team member leaves the team​
  • New team members​
  • Software that lacks any visible elements (ex — dashboard, unit tests, documentation, backend services, data stores)​
  • The Software Industry itself — New languages and frameworks with short shelf lives​
  • By moving the commissions' calculation to the Homepage, traffic on that call went from 10x/second to 1000x/second.
  • The original design required the algorithm that builds the commission amount must run a very complicated query against the Sales database. The queries are proven to be slow and taxing on the data stores. Given the extra traffic, query performance is even worse.

The Impact of Technical Debt

Some side effects of unmanaged technical debt:​

  • Systemic Death by a thousand slices​
  • Burnout​
  • Unmanagable Knowledge Debt​
  • Attrition ​
  • Unmodifiable Source Code​
  • Assets turn to Liabilities
  • Team Morale drops ​
  • Velocity slows down​
  • Business relationships suffer​
  • Total Cost of Ownership goes up


Technical Debt is a byproduct of change over time. It is inevitable in the development of products and systems. Left unattended, it can have expensive ramifications.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store