All Posts

What is Technical Debt?

software development partner for private equity firms

You may have heard software developers and project managers talk about “technical debt”. This term has been around since the 1990s and is growing in popularity. But what is technical debt and why do people keep talking about it?

What is Technical Debt?

In software development, it’s fairly common to write a quick solution based on partial information, knowing that this component will need to be refactored later. “Technical debt” describes this need for future rework resulting from an expedient software development solution.

Here’s a stab at defining the term:

technical debt n. a condition in a software development project such that one or more of its features will need future refactoring due to decisions made early in the development process. Such decisions may have been made in order to accelerate development or testing of other features or to create an iterative solution when requirements are only partially defined. Origin: Ward Cunningham, 1992; additional clarification, 2009.

A useful metaphor

Programmer Ward Cunningham, who has made so many significant contributions to the computing world, was the first person to use the debt metaphor in relation to software development. In a report at the 1992 OOPSLA Conference, Cunningham wrote about the pitfalls of immature code. Sure, it may work, but it won’t be sustainable in the long term unless the programmers go back and consolidate. He used the analogy of financial debt to describe what can happen: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.”

Is technical debt bad?

Many people shy away from debt automatically. To them, any debt at all feels like too much risk. Technical debt can provoke the same reaction.

Ask a programmer for a layperson’s example of technical debt, and you’ll probably hear about the “Y2K crisis”. It’s a classic example of technical debt. In the mid-twentieth century, computing was in its infancy and digital storage was very expensive. As a result of this budget constraint, programmers opted to store only two-digit years: they stored “1959” as “59”. That was a great solution at the time, but the solution stayed in place even after the problem went away. For years after the price of storage plummeted, two-digit years remained the standard. Programmer Bob Bemer warned about the problem as early as 1971, but it would take decades and over $100 billion just in the USA to fix the problem in time. The longer you wait to repay technical debt, the more it costs.

But why not write the fully robust solution the first time?

In other types of work, especially construction, there are adages like “Measure twice, cut once.” People want to get it right the first time. That’s not always possible or even advisable in software development. Requirements may not be complete before certain features are needed. Development and testing of a program may uncover new use cases or new data conditions. Programming best practices almost always include iterative development: create basic functionality with a few key features, then test and refine until the full scope is complete.

Just as there may be good reasons to incur financial debt — how many people pay cash for a house? — there can be good reasons to incur technical debt. It’s a very fitting analogy. Like financial debt, conscious management is the key. The two-digit year implementation solved a real problem when it was first developed. Like every solution, though, it needed periodic evaluation and refinement. Technical debt only becomes a problem when it’s allowed to accrue too much interest. Managed well, it becomes a tool for developing better software faster.


Technical debt is known future rework that results from early software development solution decisions. Like financial debt, it can be a useful tool if it’s repaid promptly or a heavy burden if it’s allowed to grow.

If you’d like more information about custom software development, click here.

Recent Posts

My Personal Development Toolkit & History

I was just on the This Life without Limits podcast: audio here and video here! Purpose of this Post I wanted to compile a master list of concepts I’ve learned to drive personal transformation and how those concepts can be applied to one’s business / professional life. There is more content to come, but there’s […]

The Role of Technology in Scaling IA Firms

Embracing AI, mobile apps, and modern claims management systems as a growth lever can mean all the difference for your business. Insurance adjusting is a competitive industry, and client demands constantly change. Firms seeking to scale their business must apply foresight, strategy, and the right technology. It’s the only guarantee they’ll process claims efficiently while […]

The 4 Stages of Growth of an IA Firm

Challenges abound throughout an IA firm’s lifecycle. Strategic planning, adaptation, and technology partnerships can ensure success. The lifecycle of an independent adjusting (IA) firm comprises different stages, each with unique challenges and opportunities. Early on, there’s a high growth potential, but limited resources and a lack of an established track record hold the company back. […]

Reducing Costs through Innovative Claims Management Solutions

Eliminate manual processes and automate claims processing with innovative Susco solutions. This will cut costs and streamline workflows. Key takeaways: The inefficiencies inherent in traditional manual claims processing take a heavy toll on insurers: stacks of paperwork inundate employees’ desks, data is scattered across disparate locations, stakeholders are in the dark about the status of […]