Technical debt. A term you all are all too well familiar with. And in the course of your career, you might’ve encountered some form of it or the other. Often, software development comes with its hangups and quick fixes appear as the best solution for them. But, as we all know, quick fixes are not long-term solutions, and sooner or later they will come back to haunt you. To ease up the dramatics, technical debt doesn’t always come in the worst form. Despite that, it’s beneficial to identify technical debt for what it is and what type it is. 

To make things easier, we’re going to focus on Martin Fowler’s technical debt quadrant which identifies the types of technical debt based on intent and context. Some are a bit riskier and bigger offenders than others, but all bring certain consequences in the end.

The infamous technical debt quadrant

You all probably know what technical debt is, but let’s refresh our memory.

So, technical debt, coined by Ward Cunningham, is the consequence that turns up in the future when businesses do not fix current problems. In software development, it means favoring speed and delivery over the quality and longevity of a software solution. They are intentional, or sometimes not so deliberate, actions that can limit and cause the reworking of the solution later on.

What exactly causes technical debt? Well, there are many things, so we’ll try to sum it up. Some of the most common causes are bad project requirements, bad or rushed code, lack of documentation, insufficient testing, information and data silos, time pressure, lack of skills, and so on.
Martin Fowler divides such technical debt into four dimensions: reckless, prudent, deliberate, and inadvertent. All of these mix and match to create four quadrants as seen on the graphic.

Source: Technical debt quadrant by Martin Fowler

When you look at separate quadrants, we can identify these: Deliberate and reckless, Deliberate and prudent, Inadvertent and reckless, and Inadvertent and prudent.

Deliberate and reckless

This happens when the team knows that their actions and prioritizing speed over quality will result in debt. They are familiar with the possible consequences and costs, but they still move forward with such decisions, which makes them reckless. 

The team makes conscious decisions, but they are not fully prepared for what’s to come. Without proper research and risk awareness, projects will fail in the long run, since the costs outweigh the profit or gain. This quadrant is definitely the one to bypass since it implies self-destruction.

Deliberate and prudent

Quadrant with these specifications means that the team knows which consequences will happen and they are aware of the future costs and technical debt. But despite that, they move on with their work. Here the debt is surpassed by the gain. 

In this case, there is a plan to go back and pay off the debt, fix issues, and apply best practices in coding after the goal is reached. It’s not about blindly going into the project. It’s about having a full analysis and understanding of possible issues, but they are reduced to a minimum so a project can be delivered.

Inadvertent and reckless

This is probably one of the most sensitive and harmful forms of technical debt since the team is not even aware that their actions are going to lead to some serious consequences. Recklessness, lack of skills and knowledge, and hurrying to finish a project are the causes of such debt. 

Here, because people are unaware they’re entering debt, they have no plan or concrete actions on how to handle future issues or negative impacts

Inadvertent and prudent

Here the technical debt is the result of an experienced team that happened to come across unexpected issues or unseen mistakes. But, due to their skills and knowledge, the team can pay off the debt later on and form plans to handle it. 

This quadrant is about finding better ways to design and program software, so developers are constantly learning and innovating. Even when they delivered the solutions, they think of ways to improve it and go back to redefining better approaches to design and development.

When technical debt gets in the way of growth

By its definition, technical debt will most certainly get in the way of growth, not only in terms of delivering software that will possibly have issues later on but also in terms of limiting the growth of developers themselves. 

Depending on the technical debt quadrant, some of their characteristics obstruct growth. Also, the level of developers’ expertise and skills will define in which quadrant the debt is. For example, inadvertent and prudent stimulate growth and personal development, unlike the other three. What makes a difference is identifying debt on time and making specific plans on how to tackle it. 

If you find yourself in a reckless area, you should reassess your approach toward projects. Because, if you constantly find yourself on the left side of the matrix as seen in the picture above, you are not being careful and sensible about your development process and possible technical debt. This will lead to technical debt accumulation and vastness of costs, issues, and setbacks. 

How to avoid and minimize technical debt

Handling technical debt is a delicate matter that has a variety of approaches. No matter which quadrant it is, it seeks special attention and a way of handling it. It may not be necessary or even possible to completely eradicate it, but you have to learn how to manage it so you can pay it off. Because, sometimes taking out a loan is good when you need to deliver something faster, but be careful of how you will take care of that loan so it doesn’t get out of hand. 

But, in case you need some advice on how to manage it, let’s take a closer look at some tactics.

Properly track issues and when you accumulated technical debt

Documentation is everything. Stay vigilant and track every change that may cost you later on. Each debt you know will happen needs to be marked down and have its appropriate solution. The correct way to go is to keep notice of everything so you know when something happened, why, at what cost, and how can you solve it.

Prioritize tasks

The worst way to go about it is to do everything at once. Which of course is wrong. Prioritize those tasks that you know you can achieve with minimal or no technical debt. Define what is achievable in a given time frame and according to coding standards.

Follow code standards and reviews

This can’t be stressed enough. Follow coding standards and reviews. Avoid rushed or bad code when possible, and review and test everything. If you make sure everything is done with best practices in mind, you will avoid bugs or code refactoring later on.

Have regular technical debt discussions

Make sure that your team is aware of the technical debt. Create meetings where you discuss the state of debt and your plan on how to solve it. Each team member should know about the consequences of each decision and track debt at each point. This is a sure way for everyone to contribute to providing the best possible solution.

Weight out the cost of rushing to deliver over strong quality code

A cost-benefit analysis is a good way to see if the cost of the debt will be greater than the gain. This is where the team has to see if rushing with the project will pay off or if the cost of repairing things, later on, will be too much.

Allocate 12-20% of sprint time to address debt and issues

Take time out of sprints to discuss and manage debt and possible issues that might arise. Don’t go forward with doing backlog items if you haven’t addressed issues that might compromise the quality of development. Define what the definition of done (DoD) is and when is a ticket closed and the task done.

Quadrants don’t solve, they tell why

Technical debt quadrants aren’t solutions, they help you identify what kind of debt you have, how did it happen, and what is its nature. As said before, the approach to technical debt will vary on the situation. There are no strict rules or guidance on how to diminish technical debt since no project or team is the same. 

Quadrants are here to tell you how the debt originated, meaning what kind of behavior did the team exhibit, so you could control it in the future. Use the quadrants to know where you stand and what you need to improve. Nothing ever is flawless. If software were, we wouldn’t have bugs. The technical debt actually indicates the quality of software development deteriorating. It’s up to the software development team to catch themselves on time and push in an upward curve rather than downward. Internal organization and on-time quadrant identification are guiding stars in avoiding too big of technical debt. 

It is known that the technical debt quadrants are a metaphor that stimulates attitude toward consequences and solutions. It helps you understand it, mark it, and tackle it. Don’t avoid talking about technical debt, rather make it a standard procedure to keep an eye on it.