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 […]

Preserve Data Quality – Prevent Errors with Technology and Build a Culture of Data Integrity

Data errors cost you more than you realize. Make better decisions and more money. Data accuracy is essential in insurance adjusting firms – it directly impacts your ability to make informed decisions and assess claims. It informs decision-making, improves efficiency, enhances customer service, and mitigates fraud. Data errors have many consequences, including incorrect assessments, claim […]

Reducing Customer Support Costs with Intuitive Software

Discover how replacing non-intuitive software with efficient solutions gives you an edge from a financial and operational perspective In the world of insurance adjusting, time is money. Yet, all too often, inefficient software drains both, leaving firms scrambling to keep their heads above the water and meet customer expectations.  Luckily, the situation isn’t all doom […]

Your Make vs. Buy Software Decision Greatly Impacts Your Business Success

Let’s compare off-the-shelf with custom software for insurance adjusting One of the most difficult aspects for insurance adjusting firms seeking digital transformation is the decision to make or buy software. It’s a strategic dilemma: Do you develop a custom software solution or purchase an off-the-shelf insurance software solution? What aligns best with your business goals, […]