Introduction to the Technical Debt Concept

Added to Technology

by Jean-Louis Letouzey and Declan Whelan

Contributors: Thierry Coq, Jean-Pierre Fayolle, Tom Grant and Dan Sturtevant

Special thanks to Ward Cunningham for his review

 

Introduction to Technical Debt from Agile Alliance on Vimeo.

Download PDF

What is Technical Debt? Where  does it comes from?

Ward Cunningham, one of the authors of the Agile Manifesto, once said that some problems with code are like financial debt. It's OK to borrow against the future, as long as you pay it off.

Since Ward first used this metaphor, which he called “Technical Debt”, it has gained momentum. While people still disagree about the exact definition of technical debt, the core concept identifies a serious problem that many software teams are struggling to manage.

Ward used it the first time when he was developing a financial application in Smalltalk. He wanted to justify to his boss the refactoring they were doing, so he used a financial analogy:

If we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan.

Later, in 1992, at the OOPSLA conference, Ward provided additional details (slightly paraphrased here based on feedback from Ward):

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 stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.

Ward elaborated further in a highly viewed video

With borrowed money you can do something sooner than you might otherwise, but until you pay back that money you will pay interest.

I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Ward also provided additional clarification during a later interview:

We can say that the code is of high quality when productivity remains high in the presence of change in team and goals.

I would say that debt is localized within a team, its goals and the code offered by a team to meet those goals. However, any mechanism that attempts to measure team commitments, goals alignment and code quality across organizational boundaries would be valuable in our increasingly dependent world.

In reviewing this paper Ward added:

There is an implicit assumption when I speak of repaying debt that the owners of the software want to save the value invested in the software for ongoing development. This is not always the case. It might make business sense to pile debt into software if a liquidity event is on the horizon. This is where business strategy meets engineering strategy. A startup, for example, is building both a product and a company. Can the investors be criticized for maximizing their returns? Or is this just another version of bait and switch?

We could summarize the metaphor as follows:

When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt.

Why do we use this metaphor?

The Technical Debt concept is an effective way to communicate about the need for refactoring and improvement tasks related to the source code and its architecture.

If you are able to estimate roughly the time needed for fixing what is not right into your code, the principal of your debt, you could compare this information to other project data, like remaining days before release date. This estimation will help you to understand your situation and plan repayment activities.

What incurs Technical Debt?

Code that is not quite right may include many types of issues. These issues may be related to architecture, structure, duplication, test coverage, comments and documentation, potential bugs, complexity, code smells, coding practices and style. All these types of issues incur technical debt because they have a negative impact on productivity.

Technical Debt may emerge during the life of a project. At time progresses you may understand something new about your application domain. You may now view your initial architecture as having acquired technical debt.

Are there other types of debt?

Not all software projects issues are Technical Debt:

  • Identified defects are not Technical Debt. They are Quality Debt.
  • Lack of process or poor process is not Technical Debt. It is Process Debt. An example is Configuration Management Debt.
  • Wrong or delayed features are not Technical Debt. They are Feature Debt.
  • Inconsistent or poor user experience is not Technical Debt. It is User Experience Debt.
  • Lack of skills is not Technical Debt. It is Skill Debt.

Is Technical Debt bad?

Taking short cuts in order to put earlier a viable product on the market which delivers business value is generally not a bad decision. But one should be conscious that  the Technical Debt incurred will hurt sooner or later.

At some time, the team should pay back at least a part of the accumulated Technical Debt.  They are different ways to do that, and there is no magic one that fits all situations. In order to fully understand the situation and establish the relevant strategy, the Technical Debt should be made fully transparent and analyzed.

How to analyze TD?

All the Technical Debt items are not the same. In order to understand the situation, in order to select and prioritize refactoring or improvement activities, it is important to analyze them. The following table provide a list of aspects that shall be taken into account.

 

This list represents the good sense that teams should apply, and is largely self explanatory. However, it is worth saying a few more words about the last point.

To prioritize repayment tasks, it is important to identify and assess dependencies between scopes of changes. As an example, it will be mindless to fix two issues located in two instances of a duplicated block. It is more efficient to first fix a copy and paste issue and then to fix the remaining issue within the remaining block.

Other external aspects should be considered for selecting and prioritizing refactoring activities, including:

  • The business value of the component.
  • History, age and future decommissioning of the component.
  • The probability of getting a negative impact (it depends on the usage and the change frequency of the piece of code where the TD item is located).

So, what to do?

The Technical Debt concept is quite simple. When looking into details, it appears that they are many aspects to consider for analyzing and managing the situation.

We have consolidated a list of recommendations and best practices in the document: Project Management and Technical Debt

 

About the Authors

Jean-Louis Letouzey is the author of the SQALE method for managing technical debt. Jean-Louis consults to the world’s leading organizations for the implementation of corporate solutions for managing technical debt. He is also frequently embedded in due diligence teams for assessing the technical debt of the acquired software. Jean-Louis is a frequent technical speaker at international conferences. He leads the Technical Debt Initiative of the Agile Alliance

Declan Whelan, declan@leanintuit.com. Declan is an agile consultant, co-founder of Leanintuit and a director at the Agile Alliance. Declan works with organizations to improve their products and services through agile and lean practices. His personal mission is to change the conversation around technical debt. Rather than viewing is a technical problem to be fixed we need to view it as valuable feedback of the health of our organizations. We can use these health checks to improve our product and service delivery.

Thierry Coq is a Principal Consultant and Surveyor in Systems and Software Reliability (SSR) at DNV GL (merger of “Det Norske Veritas” and “Germanischer Lloyd”). He is a Systems and Software Architect, Functional Safety Professional, Project Manager and Process Appraiser. He is and has been involved in large multi-site projects, in different industries: Aerospace, Nuclear, Automotive, Energy and Maritime. He has a drive on improving organizations’ and project teams’ processes efficiency and speed with a focus on reliability and safety, with an excellent understanding of deep technical issues. He is a co-author of the Integrated Software-Dependent System (ISDS) Recommended Practice and Offshore Standards published by DNVGL. He has participated in the construction of the SQALE software quality assessment method with Jean-Louis Letouzey. He is the author of the book “Méthodes et informatique: Réussite du projet informatique par la méthode”, Lavoisier, 2012 (“Making software projects successful with method”) and has published many articles. Previously, he was new technology manager, project manager and engineer at engineering firms Q-Labs, Dassault Systems and CISI.

Jean-Pierre FAYOLLE is a French expat, located in Madrid and working as a freelance consultant in Software Quality and Customer Success Management. Prior to this, Jean-Pierre was Technical Director or Head of Applications and Development for different software companies or service providers, with ample experience in consulting and implementing software solutions for large international companies. Jean-Pierre holds a Master of Advanced Studies in Business Administration from the University of Lyon (France) and in Computing Management from the University of Quebec (Canada). He is the founder and main author of the blog Qualilogy (www.qualilogy.com), about Software Quality.

Tom Grant is an independent consultant (GameChange LLC) who help clients break through the barriers to successful software innovation. In his practice, he combines Agile, Lean, and serious games to change the rules of innovation when they're not working as well as they could. Tom has worked with a wide variety of clients, from Fortune 100 companies to start-ups, from IT to software companies.Some of Tom's areas of specialization include technical debt, Lean and Agile, management and leadership, Agile in highly regulated industries, requirements, tools, and frameworks. Tom's great passion is using serious games in Agile to get better customer insights, test strategies through simulated outcomes, adopt new practices and principles through experiential learning, and make smarter decisions.Tom is a contributor to the Agile Alliance's working group on technical debt. Previously, Tom has worked as practice director at Cutter Consortium, as a consultant at Net Objectives, and an analyst at Forrester Research. A native Californian, Tom now lives in Washington, DC.

Dan Sturtevant is the CEO of Silverthread, Inc., a leading provider of tools and services that help organizations regain control of software systems and drive results by focusing on design quality and its long term impact on long-term maintainability, agility, and cost. Based on R&D done at MIT and Harvard Business School, Silverthread helps organizations build insight and systematically improve so that systems can be delivered on time with high quality, and so they remain adaptable in the face of change. Dan earned his Doctorate from MIT, where he measured development productivity, quality, and risk in complex codebases. Prior to cofounding Silverthread, Dan spent many years in the software field building supercomputers used in aeronautical design simulation and developing defensive cyber warfare systems.

Agile Alliance is a nonprofit organization with global membership, supporting and serving the Agile software community since 2001. We support people who explore and apply Agile values, principles, and practices to make building software solutions more effective, humane, and sustainable. We share our passion to deliver software better every day.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.