Technical Debt Quadrants

How To Tackle Technical Debt Quadrants?

Technical Debt Quadrants

You come across the term technical debt, read a little about this matter, know everything in theory, and you’re still not sure how to correctly identify whether some kind of design flaws are actually technical debt or not. 

We have a solution that can help you with this issue – Technical Debt Quadrants. This method of identifying technical debt is becoming increasingly popular because of its unique approach. Instead of focusing on whether the problem is real or not, it recognizes a type of technical debt.

Here you will learn everything you need to know about Technical Debt Quadrants’ concept, what it does, and how to use them. Let’s face it!

Technical Debt Quadrants: what is it?

To properly understand what the Technical Debt Quadrants are, let’s begin with a few words about technical debt. 

Technical debt

Technical debt (you can also come across on the term design debt) describes the situation when delivering useful features give short-time benefits, and it’s more important than the costs that it can bring. In this case, costs don’t strictly refer to the financial aspect, but they can also relate to the product’s quality or other factors that suffer because of the implementation pace. Under time pressure, developers make a considered decision to launch an incomplete product, assuming that they will make proper improvements later 

 (to learn more about technical debt, check the first article of this series). 

Whereas the Technical Debt Quadrants analyze this theory a step further and develop technical debt identification methods. 

Technical Debt Quadrants

Technical Debt Quadrants is a concept shown on the useful diagram that helps to identify the technical debt by its nature. It enables the software developers to decide whether it would be a strategic move or not.

It contains four squares of the box that help to determine the reason for occurring technical debt. Created by Martin Fowler, a software development specialist, it becomes a popular idea of classifying technical debt into four categories, based on intent and its context. By studying the Technical Debt Quadrants, you can learn about the choices made in the case of design flaws.

The developer of this concept pays particular attention to these four variables: Deliberate, Inadvertent, Reckless, and Prudent. He considers it necessary not to define whether technical debt exists but rather to learn how to identify it.

How should you interpret each square of this diagram? 

Q1: Deliberate + Reckless

“We don’t have time for design.”

The first quadrant refers to situations when the development team knows exactly that a decision they make will result in technical debt. Undertake it consciously but are not ready for it at all. They ignore whether the costs of paying off the debt would be greater than the profit gained from the earlier release. The team feels the pressure knowingly violates the best practices.

The team with deliberate and reckless debt doesn’t have even a draft of the plan. If the developers don’t know what impact this decision will have, they don’t analyze whether their budget will be sufficient to make proper changes, and they don’t care about the consequences of the technical debt. 

A deliberate acquisition of technical debt without adequate research is a rarely practiced strategy (if it can even be called that). Even though scale-ups and start-ups work under immense pressure, they don’t choose to make such a reckless approach. The decision to ignore technical debt can result in huge losses and irreversible mistakes that can destroy a company forever. 

An example of Deliberate and Reckless technical debt:

The company is about to launch a great product. A few days before the launch, the testers discovered numerous obstacles and errors in the new software. However, even though they demand improvement, the company decides that they have no time for it and want to implement the product anyway. What happened after that? The launch of the product was a disaster, the servers went down, and the company gained such hostile opinions that they had to recall the product. Probably the market would not give them a second chance, and they will be forced to close their business or start operating under a different brand name. 

Q2: Deliberate + Prudent

“We must ship now and deal with the consequences.”

A prudent attitude is based on planning and thinking for the future. A company knows their decision will cause technical debt, but they are aware of the consequences and wish to prevent them, unlike the first quadrant approach. 

It’s all about priorities. Developers need to choose between the most important features, and those without the product will still be satisfactory. The platforms work well, but the search algorithm is crawling. This bug will probably have no impact on the basic functionality, and the developers can postpone the work on it after the implementation.    

However, developers are aware of these gasps, and while they are launching the product, they will all the time keep in the back of their minds that it’s not completed yet. They assume that shipping an unfinished product quickly would offer greater benefits than costs. 

In this case, developers can learn from their mistakes and constantly improve the product to introduce further changes. Such an approach is a good one – sometimes, small errors are found only after implementation, and if the company had not launched the product, developers would have never discovered them. 

An example of Deliberate and Prudent technical debt:

A company prepared for the launch of their new product months before. They are aware that the deadline chases them, so they decide to put some small bugs aside and analyze whether these flaws will have further consequences. The company chose to ship the product as quickly as possible with the scratch on the code. They were ready to deal with the consequences, so it turned out that their rush had paid off – they avoided a delay and stayed prepared to make quick adjustments after implementation. The product is proven to be a huge success. 

Q3: Inadvertent + Reckless

“What’s layering?”

The third quadrant refers to the situation when the company ignores all the best practices and, from the beginning, makes vast mistakes in its code, creating an ever-growing technical debt. They’re not aware of the problems (or don’t want to be) and adopt the tactic – “we will ignore errors so that they may disappear.” 

Since specialists have expertise in the IT industry, it can be expected that they know what their good points are and where they still need to expand their knowledge. The real problem is when they can’t recognize their knowledge gaps and don’t even want to do so. 

It can be assumed that the developers should have been able to tackle such basic code issues and not allow for such a large build-up of technical debt. This approach can result in inadvertent and reckless technical debt – they didn’t know about the design flaws, which were easy to predict. 

An example of Inadvertent and Reckless technical debt:

The company hired IT experts to develop a new product. The management trusted them entirely, so they didn’t supervise the progress of the project. Unfortunately, it turned out that they made a lot of basic mistakes along the way. They overlooked the issues and launched the product anyway. There is no place for good quality; the base code is so buggy it’s too late for any changes. One way out of this situation is to refactor code but keep the functionality practically the same, or even build a new system from scratch (if there’s still a budget to do so). Making an inadvertent and reckless decision does not seem to have been a rational choice at all. 

Q4: Inadvertent + Prudent

“Now we know how we should have done it.”

This combination might sound a bit strange, but these two adjectives describe the last quadrant. Inadvertent and Prudent technical debt is not only common but also inevitable in the team of excellent experts. 

The process of software development is continuous learning and testing. So, the developers are aware that they will discover how differently they could have designed it after launching the product. IT developers strive for ongoing improvement and implementation of new solutions. 

Coding is sometimes the only way to discover something innovative. Maybe it doesn’t seem so, but this technical debt quadrant is one of the most challenging. You can make numerous analyses and predictions, but only implementing the product and its life can truly show you the code improvements. It sometimes takes years before developers find the best solution for the design approach.

An example of Inadvertent and Prudent technical debt:

This example should describe every development company. After launching the product, the client was delighted. Even though developers, after implementing the features, feel satisfied, they at the same time realize that it isn’t completely perfect and needs improvement. They constantly seek to improve the product, and, likely, they will never call it flawless. 

Technical Debt Quadrants: how to use them properly?

Now when you understand the interpretation of each quadrant, what about its usage? How should you identify which quadrant refers to your company situation? The use of Martin Fowler’s concept isn’t regular, so you cannot go step by step to tackle the technical debt. It’s a much more complicated process, and this can only be a helpful add-on. 

First of all, you need to ask yourself whether you were aware of technical debt existence or have no idea about it. When you answer this question, you will find whether your technical debt is deliberate or inadvertent. Then, find the distinction between prudent and reckless decisions. Do you take into account costs and benefits? Are you familiar with technical debt consequences?

Technical Debt Quadrants don’t give you a ready answer; it’s just a useful metaphor that can help you understand your technical debt’s nature. 

It would help if you remembered that the best practice is the second quadrant (Q2): Deliberate and Prudent debt, and this approach should strive for all developers and software projects. You should avoid the quadrants placed on the left side of the diagram (Q1 and Q3). If your company is located in one of them, you need to make everything possible to be changed as soon as possible (at least you’ll know whether the technical debt is helping you or not yet). You should now be able to categorize your technical debt into one of these four categories. 

A metaphor of debt

A study conducted by Stripe found that developers spend nearly half of their time dealing with technical debt. They estimated that this costs $85 billion per year. It confirms that bad code is a real problem during product software development, and good recognition of the technical debt can have a huge impact on the product’s success. Not surprisingly, the subject of dealing with technical debt becomes increasingly popular.

Technical Debt Quadrants are a helpful metaphor to define your types of technical debt. If it turns out that your development project struggles with technical debt, it’s the right attitude that will help you to understand it and tackle it properly. 


Read more

Download e-book:

Scalac Case Study Book

Download now


Tomasz Bogus

Tomasz Bogus, Head of Business at Scalac. Tech entrepreneur, startup co-founder. For over 15 years, he’s worked with more than 2000 successful companies helped them achieve faster growth by embracing the newest IT technologies.

Latest Blogposts

17.04.2024 / By  Michał Szajkowski

Mocking Libraries can be your doom

Test Automations

Test automation is great. Nowadays, it’s become a crucial part of basically any software development process. And at the unit test level it is often a necessity to mimic a foreign service or other dependencies you want to isolate from. So in such a case, using a mock library should be an obvious choice that […]

04.04.2024 / By  Aleksander Rainko

Scala 3 Data Transformation Library: ducktape 0.2.0.

Scala 3 Data Transformation Library: Ducktape 2.0

Introduction: Is ducktape still all duct tape under the hood? Or, why are macros so cool that I’m basically rewriting it for the third time? Before I go off talking about the insides of the library, let’s first touch base on what ducktape actually is, its Github page describes it as this: Automatic and customizable […]

28.03.2024 / By  Matylda Kamińska

Scalendar April 2024

scala conferences april 2024

Event-driven Newsletter Another month full of packed events, not only around Scala conferences in April 2024 but also Frontend Development, and Software Architecture—all set to give you a treasure trove of learning and networking opportunities. There’re online and real-world events that you can join in order to meet colleagues and experts from all over the […]

software product development

Need a successful project?

Estimate project