Software Technologies - Home
When Will You Pay Back Your Technical Debt?
Christof Ebert
NOV 23, 2012 14:00 PM
A+ A A-


Debt is bad. We hear this simple rule from parents when they educate their children on the proper use of money, from politicians when they try to control economy, and of course from our managers when we try to sell a proposal which needs investment. Expenses should be done from our earned money. On the other hand, success often stems from borrowed money. Apple was started in 1976 with borrowed money from an Intel executive. Later Steve Jobs borrowed millions from Bill Gates to turn around the loss-making Apple. There seems to be good and bad debt.


A good debt is one which we carefully use to evolve our products, make money, grow our business, and pay our debt back. Bad debt on the other hand is expenses which are waste and without any plan how to pay it back within a reasonable time. Technical debt as a metaphor had been coined exactly on this simple wisdom that there are good and bad debt. My own definition is pretty simple: Technical debt are the eventual consequences of poor engineering of a software product for short-term benefits that make the same work cost more to do later. Engineering needs money. If done insufficiently, the money is wasted. If done to achieve short-term benefits, such as keeping a deadline at the cost of defects to be corrected later, we run into technical debt. And like our parents or politicians had warned us, we will never really catch up, because the product evolves faster than we have the energy to pay back.


Meir Manny Lehman described this pattern in 1980: “As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.” Generations of software engineering students had been confronted with this simple truth, but not all comprehend. In consequence they repeat the same errors over and over again, first as engineers and then as managers.


In 1996 the Netscape Navigator had a market share of 80%, while Microsoft’s Internet Explorer had 20%. In Internet times this should be enough to make it a fat cash cow for decades. You just invest enough to stay ahead, and earn the money. Yet, in 2002 Microsoft had a market share of 96% and Netscape a mere 2%. What had happened? When founded in 1994, Netscape had a wonderful and unique product to access the Internet. They evolved it very fast, but gradually lost control about how the features relate to each other and how to maintain the code. Speed dominated engineering and quality. The code got worse with each function, while nobody realized that they accumulated a debt which could not be paid back. This brings us to a first lesson: Make technical debt visible.


The Explorer initial code also got out of control. While Netscape had insufficient feature control, no product management, poor architecture and deterring quality, Microsoft took another direction. In 1996 they made a full redesign of the Explorer, and thus even further delayed the product. Our second lesson: Evaluate trade-offs and decide. Microsoft decided for an Architecture core team, for product management, and for maintainability and portability being premier goals. Netscape on the other hand pushed Java into a new product, but again without clear architecture and product design. Eventually the company disappeared. Our third lesson: Systematically control technical debt. A while ago I have coined the RACE principle to systematically reduce technical debt: Reduce Accidents, Control Essence.


Technical debt as a metaphor is useful, but rarely practiced. It goes far beyond architecture control as more recently suggested in the agile community. It is part of product management and must be controlled by business measures. When I explain technical debt and its impact on software and IT, managers and engineers immediately understand the metaphor. When I ask them why they don’t practice above mentioned three simple rules, they come with all types of excuses, such as that technical debt cannot be measured, or cannot been valued in Dollars or Euro. This is nonsense. Useful quality measurements have been around for years. The cost of defects, late defect detection, non-quality or poor maintainability can today be translated into financial measures and into due diligence. Architecture quality can be measured. The real reason why technical debt as a metaphor is still not used much by engineers and managers is that many still think they are paid for speed, until it is too late. So you better reflect in your products, how much debt is ok, and when you will pay back the remaining debts – before they eventually strangulate you




The book “Software Measurement. Establish, Extract, Evaluate, Execute” from Springer, provides a good introduction to measuring debt and on the RACE principle. URL:    



IEEE Software theme issue on “Technical Debt”:

White Papers and resources:



Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to sustainably improve product strategy and product development and to manage organizational changes. An IEEE senior member, he serves on a number of advisory and industry bodies, teaches at the University of Stuttgart and has authored several bestselling books including his most recent book “Global Software and IT” published by Wiley-IEEE.

Contact him at



[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment: