Skip to content
Tiatra, LLCTiatra, LLC
Tiatra, LLC
Information Technology Solutions for Washington, DC Government Agencies
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact
 
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact

What is technical debt? A business risk IT must manage

What is technical debt?

Technical debt is the cost accrued over time from technology implementation decisions that emphasize expediency over long-term quality and maintenance. It is based on the idea that cutting corners for the sake of speed when writing code or setting up infrastructure will create more work to upkeep, secure, or manage in the future. For example, if the underlying code of an application pushed quickly into production is convoluted and difficult to update and maintain, the time or resources saved in the process of writing it will eventually need to be repaid in frustration and work down the line.

The idea was coined by legendary programmer Ward Cunningham, one of the authors of the Agile Manifesto, and he laid it out succinctly at the OOPSLA conference in 1992:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unfactored implementation, object-oriented or otherwise.

While the term technical debt found its origins in software development, the concept is applicable to a wide range of IT implementations and operations beyond custom code.

Why is technical debt important?

Technical debt is often thought of in terms of financial debt, a tool for achieving something today that would be impossible without it. Just as a mortgage can help a home buyer capitalize on a property opportunity without having the full asking price at the time of the sale, a company can keep pace with competitors and make good on market opportunities by rolling out a software product or web service before the code has been perfected for long-term maintenance. 

On the other hand, taking on technical debt in this way saddles you with burdens you’ll have to deal with for years, potentially crippling IT innovation. Just as paying off a 30-year mortgage with interest will mean having paid much more than the selling price for your house, rushing a software product out the door to get first-mover benefits can subsequently eat up lots of future person-hours from your development, QA, and customer service teams.

So, is technical debt bad? The question misses the point of its importance. Financial debt in the abstract is neither good nor bad, and there are well-defined ideas such as the time value of money that help you determine whether or not taking out a specificloan is a good idea. Similarly, the conceptof technical debt allows you to think about (and even quantify) the tradeoffs involved in software development under real-world markets and pressure.

And, extending our metaphor, there are different ways to deal with technical debt, just as there are with financial debt. You can make small, regular payments that are manageable in the short run but ultimately cost a lot over time; or you can gather up the resources necessary to pay all or most of the debt off in a lump sum. For tech debt, this could mean accepting the daily toil and lost efficiency of working with substandard code; making a conscious plan to chip away at the debt, rewriting code and addressing problems over time; or ripping and replacing with a completely refactored version at a set point sometime in the future.

Technical debt in Agile: The fact that the phrase “technical debt” was coined by one of the thinkers behind Agile project management is no coincidence. Agile frameworks are often designed to take technical debt into account and encourage teams to build regular time into their schedule to revisit old code to work off that debt. That’s part of the Agile philosophy of continuous improvement.

Types of technical debt

One way to think about different kinds of technical debt comes from an influential 2009 essay from Martin Fowler. Fowler popularized the concept of code refactoring, a process that involves dealing with a lot of technical debt, so it’s a subject to which he gave a lot of thought. His essay proposed two different axes you can use to categorize technical debt. The first is planned vs. unplanned, which is self-explanatory. The second is reckless vs. prudent, which seems similar but is not quite the same thing: Prudent debt is debt that’s accounted for when taken on or later evaluated as part of a technical debt strategy, whereas reckless debt is piled up without much thought. The two axes together create a quadrant of debt types:

  • Planned/reckless: “We know we’re making lots of shortcuts here, but frankly we don’t have time to think or deal with that — let’s just get it over the finish line!”
  • Planned/prudent: “We’ve assessed the risks of this design before we rolled it out. We know the consequences that we’ll have to deal with, and we have a plan for them.” This could be the way a team thinks when quickly rolling out a minimum viable product that they know they’ll have to revamp later once they’ve gained users and market share.
  • Unplanned/reckless: “We have a superstar team and this whole process will probably go fine!” [Later: it turns out the process did not go fine]
  • Unplanned/prudent: “We discovered some problems that arose from our initial development process, but we’re keeping on top of them, learning from our mistakes, and have a plan for remediation.”

If you’re looking to accrue the “good” kind of debt, you should be favoring planned over unplanned, and prudent over reckless.

Technical debt can arise in many areas of your enterprise’s technical infrastructure. CIO’s Isaac Sacolick outlines seven types of tech debt that could cripple your business, including data debt, open source dependency debt, and architectural debt.

Causes of technical debt

With technical debt, the devil is in the details, so let’s look at some specific drivers that lead teams to take on technical debt:

  • A rush to meet deadlines: Time constraints often force teams to take shortcuts, leading to substandard code that must be dealt with later. Your tech leadership team must prioritize tasks effectively and track postponed work to ensure it ultimately gets addressed.
  • Unclear project requirements: When goals are vaguely written or not well thought out, teams may produce code that doesn’t really align with the underlying needs. Work done early on to define clear requirements can pay off later with cleaner code.
  • Poorly written code: One of the main sources of tech debt, sloppy code makes future development and refactoring slow and inefficient; well-structured code, on the other hand, is easier to maintain and integrate with new features.
  • Inadequate documentation: If poorly documented, even well-written code will cost your team and their successors wasted time and effort down the line. Establishing strong documentation from the start may take time, but will ultimately reduce effort going forward.
  • Inevitable system evolution: Even well-designed codebases require ongoing maintenance due to evolving business needs, security threats, and outdated technologies. Code can “drift” due to dependencies on other packages or minor tweaks that have unintended consequences. In some ways this is the most insidious cause of tech debt, and should be guarded against.

How to measure and manage technical debt

One important difference between financial and technical debt: It’s much easier to quantify how much money you owe than it is to figure out your exact level of technical debt. There are techniques to help, however; for instance, in a whitepaper, CodeScene suggests a strategy in which you measure your team’s unplanned work, which is a good stand-in for time spent cleaning up tech debt they’ve inherited.

Even if you can’t hang a number on your debt, you still need to get a handle on it. Andrew Sharp, research director at Info-Tech Research Group, is a strong advocate for tracking technical debt. He advises IT leaders to document their most critical technical debt, understand its business impact, and establish a clear process for resolving it.

Understanding what technical debt you have is the first step to managing it. CIO’s Mary K. Pratt has a deep dive on how tech leaders should approach managing technical debt: You need to prioritize it on your road maps, think about it as a business risk, and be sure that when you do take on new debt, it’s in the planned/prudent quadrant. 

How to explain technical debt in the C-suite

Unfortunately, it can be difficult to convince CEOs and organizational leadership to invest the resources and personnel necessary to deal properly with technical debt. Technical debt is not a “sexy” subject; resourcing to address it doesn’t obviously contribute to revenue, and in the end, reducing technical debt doesn’t always come with any new capabilities to point to.

Here are some strategies for convincing execs to prioritize technical debt:

  • Koenraad Schelfaut explains how to talk to your board about tech debt, laying out the business-oriented lingo that will advance your cause. For instance, talk about “revenue bottlenecks” rather than “legacy systems.”
  • Management is increasingly using the concept of risk management to quantify and mitigate uncertainties facing the business. Framing tech debt as a business risk — a risk of missing out on future opportunities because of the time wasted on current problems — is one way to shift the conversation.
  • Overall, efforts to address technical debt can be tied to other projects, be balanced against other IT priorities, and be incorporated into a long-term strategic plan that shows return on investment.

You’re never going to be able to reduce your technical debt to zero. But with the right approach, you should be able to minimize and manage it — and take on more when that makes technical sense and can forward your organizational goals.


Read More from This Article: What is technical debt? A business risk IT must manage
Source: News

Category: NewsApril 15, 2025
Tags: art

Post navigation

PreviousPrevious post:La OTAN compra el sistema de IA estadounidense Palantir para operar en el “campo de batalla moderno”NextNext post:La CIO Sharon Mandell transforma Juniper Networks para la era de la IA

Related posts

Barb Wixom and MIT CISR on managing data like a product
May 30, 2025
Avery Dennison takes culture-first approach to AI transformation
May 30, 2025
The agentic AI assist Stanford University cancer care staff needed
May 30, 2025
Los desafíos de la era de la ‘IA en todas partes’, a fondo en Data & AI Summit 2025
May 30, 2025
“AI 비서가 팀 단위로 지원하는 효과”···퍼플렉시티, AI 프로젝트 10분 완성 도구 ‘랩스’ 출시
May 30, 2025
“ROI는 어디에?” AI 도입을 재고하게 만드는 실패 사례
May 30, 2025
Recent Posts
  • Barb Wixom and MIT CISR on managing data like a product
  • Avery Dennison takes culture-first approach to AI transformation
  • The agentic AI assist Stanford University cancer care staff needed
  • Los desafíos de la era de la ‘IA en todas partes’, a fondo en Data & AI Summit 2025
  • “AI 비서가 팀 단위로 지원하는 효과”···퍼플렉시티, AI 프로젝트 10분 완성 도구 ‘랩스’ 출시
Recent Comments
    Archives
    • May 2025
    • April 2025
    • March 2025
    • February 2025
    • January 2025
    • December 2024
    • November 2024
    • October 2024
    • September 2024
    • August 2024
    • July 2024
    • June 2024
    • May 2024
    • April 2024
    • March 2024
    • February 2024
    • January 2024
    • December 2023
    • November 2023
    • October 2023
    • September 2023
    • August 2023
    • July 2023
    • June 2023
    • May 2023
    • April 2023
    • March 2023
    • February 2023
    • January 2023
    • December 2022
    • November 2022
    • October 2022
    • September 2022
    • August 2022
    • July 2022
    • June 2022
    • May 2022
    • April 2022
    • March 2022
    • February 2022
    • January 2022
    • December 2021
    • November 2021
    • October 2021
    • September 2021
    • August 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    Categories
    • News
    Meta
    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org
    Tiatra LLC.

    Tiatra, LLC, based in the Washington, DC metropolitan area, proudly serves federal government agencies, organizations that work with the government and other commercial businesses and organizations. Tiatra specializes in a broad range of information technology (IT) development and management services incorporating solid engineering, attention to client needs, and meeting or exceeding any security parameters required. Our small yet innovative company is structured with a full complement of the necessary technical experts, working with hands-on management, to provide a high level of service and competitive pricing for your systems and engineering requirements.

    Find us on:

    FacebookTwitterLinkedin

    Submitclear

    Tiatra, LLC
    Copyright 2016. All rights reserved.