Technical Debt - What Is It, What Is Its Impact, And What Are Strategies To Manage It?

Building anything from scratch is a daunting task. We discussed how building or renovating a home was not unlike creating a custom software application in a previous post. It is a complex effort that involves managing a team of specialized experts. And just like building a home, your software project may involve incurring debt to make it a reality - technical debt that is.

Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. Technical debt is also known as "code debt'' or design debt." Information and Software Technology Journal explains technical debt this way:

"Technical debt describes the consequences of software development actions that intentionally or unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation, and design considerations…Conceptually, technical debt is an analog of financial debt, with associated concepts such as levels of debt, debt accrual over time and its likely consequences, and the pressure to pay back the debt at some point in time."

Ward Cunningham, Agile Manifesto author, coined the term and explained that "some problems with code are like financial debt. It's OK to borrow against the future, as long as you pay it off."

Technical Debt Is A Tool

Just as taking out a loan to buy or build a home can make good financial sense, incurring technical debt now to achieve rapid gains, such as launching on time and gaining paid subscribers to drive revenue, can make good business sense.

Repercussions of Technical Debt

However, as with any debt, technical debt comes with an inherent cost, the interest accrued. The faster a debt is paid down, the less interest you will pay. A 15-year mortgage will cost you tens of thousands of dollars less than a 30-year loan. HackerNoon explains technical debt as "interest" costs. "Technical debt occurs when you take shortcuts in writing your code so that you can reach a goal faster, but it comes at the cost of uglier, harder to maintain code. …You can accomplish more today than you normally could, but you end up paying a higher cost later." Startups need to be sure when they incur the debt that they can sustain their technical levels until they can go back, refactor, and pay it down.

Good/Bad Or Neither

Debt is a bad thing, right? It depends. Going into debt to buy a house now rather than paying rent for 15 years makes good money sense. Maxing out your credit card, knowing that you can't even pay the monthly minimum, is fiscally irresponsible.

Startups feel significant market pressure to "ship or sink." Trading off a launch of a "good" product now to gain market share and assuming technical debt often makes much more business sense than waiting to release a perfect application and losing out to a competitor.

Types of Technical Debt

Just as financial experts have varying opinions on economic theory, the software development community has differing thoughts on technical debt. Steven C. McConnell, well-known software engineering and project management expert, classified technical debt into intentional and unintentional. The former being a strategic decision, the latter being the result of "doing a poor job."

Martin Fowler expanded upon McConnell's concept, categorizing technical debt into categories based on intent and context. He published the now well known "Technical Debt Quadrant" with examples. He noted that their placement on the quadrant indicated whether taking on the debt was prudent or reckless.

A study published by Software Engineering Institute in 2014 further delved into the topic and classified technical debt into functional categories. They identified 13 distinct types of technical debt and a set of key indicators for each.

1. Architecture Debt
2. Build Debt
3. Code Debt
4. Defect Debt
5. Design Debt
6. Documentation Debt
7. Infrastructure Debt
8. People Debt
9. Process Debt
10. Requirement Debt
11. Service Debt
12. Test Automation Debt
13. Test Debt

Impact of "Unpaid" Technical Debt

While technical debt is not inherently bad, and most software has it to some degree, being aware of the real "interest" costs will help you balance them with the opportunities carrying the debt offers your company.

Decreased Velocity

Maxing out your credit cards causes debt to become a hindrance rather than a tool. You first must pay down interest before you can leverage the obligation to make new purchases. Accumulating too much technical debt works the same way. If your team is at its capacity just to maintain product functionality, your ability to innovate and deliver additional value to your customers will be delayed.

Decreased Quality

By its nature, technical debt involves a trade-off between speed and quality. Thoughtful consideration must be given to:

• Quality Assurance - Does the product meet the core business/customer requirements?
• Quality Control - Does the product have high internal quality/functionality?

If you answer no to either or both of these questions, it is an indicator of areas to be addressed to avoid customer dissatisfaction and costly rework.

Real-World Example

While technical debt occurs in most software rollouts, the larger the project's scale, the greater the chance that crippling consequences will occur. The launch of HealthCare.gov, a critical component of the Affordable Care Act, is widely considered a miserable failure. The website's first day live across 36 states; only SIX users could complete their registration. The site was down over 57% of the time!

Less than three weeks after the launch, President Obama and his Chief of Staff created a task force charged with reworking the site. The successful rollout cost an estimated 1.6 billion dollars more than the original budget.

The HBS Digital Initiative outlines some of the root causes of the site's failure.

• Lack of relevant experience - HHS employees had significant experience with insurance markets, but little expertise with technology product launches.
• Lack of leadership - There was no formal division of responsibilities between government departments, and no clear leader of the initiative. This created communication issues and delays in decision making. For example, the contractor responsible for the logon system underestimated the demand because the initial plan did not consider that all users would need to sign in to the marketplace to shop for plans. Scope changes were not communicated to the vendor, and the logon part of the application created a bottleneck.
• Schedule pressure - Since the launch date for the site was a mandate of the Affordable Care Act, HHS employees were under significant pressure to launch on time.

Quantifying Your Technical Debt

Taking inventory of your debt is the first step in managing it. Financial tools abound, but how do you measure levels of technical debt. Researchers have estimated that the cost to eliminate structural-quality problems is approximately $361,000 per 100 KLOC (100,000 lines of code) in a program.

Scrum Expert outlined various tools that can help you assign a dollar value to your project's technical debt. "Some might provide "absolute" information, like the violation of a coding standard, and others will produce "smells" that need to be examined manually." They list various programs that, when used together, will provide trends to investigate. They added,"…. you should not expect a solution that will compute a precise number… even if some companies have done this. Each project has its own context, and each software team and developers have their view on what is acceptable. Multiple reports from these tools will, however, provide you with a trend."

Strategies To Manage Your Debt

All technical debt has to be repaid, right? Well, again, it depends. Each organization needs to measure the pros and cons of paying off or maintaining technical debt.

There are three main strategies to manage your debt:

1. Repay it - Refactor/replace the code, framework, or platform that is creating the debt. Think of this as paying off all your credit cards.
2. Convert it - Replace the portion of your application, causing issues with a better but not perfect solution. Think of this as refinancing your mortgage to a lower interest rate.
3. Pay the interest - live with the challenging code and deal with bugs as they arise. Think of this as paying a higher interest rate on a loan as it would be too time-consuming and costly to move into another financial product.

While incurring technical debt may be an unavoidable part of the software development process, partnering with experts who have managed similar projects across a variety of domains can help make your journey less daunting. You would not attempt to traverse complicated financial filings without a CPA or tax accountant. An experienced software development partner can help you create a "technical debt plan" for your organization and, just like your financial planner, will be your guide through changing conditions.