Technical debt is a common metaphor for software's accumulated backlog (like bugs, missing documentation, and legacy code). It can happen because developers favor a “quick and dirty” over a more polished and clean solution to reduce the overall implementation time and meet strict deadlines.
Today we’re focusing on the main types of technical debt. Countless academic papers, articles, and blog posts have defined types of technical debt. The most accepted definition is Martin Fowler’s Technical Debt Quadrant. Other definitions use different terminology, but the concepts are similar to those presented by Fowler.
Martin Fowler’s technical debt quadrant
According to Martin Fowler, a software development specialist, there are 4 different types of technical debt, with some being riskier and having more nefast consequences than others. The technical debt quadrant categorizes these types of tech debt based on intent and context. You should avoid the left side of the quadrant at all costs.
Technical debt quadrant from Martin Fowler’s post
Deliberate and reckless
Deliberate and reckless technical debt happens when the team knows that a particular decision will result in tech debt but still moves forward because it prioritizes speed over quality. However, the team might not understand the repercussions of that decision. The team does consider aspects like long-term impact and the approximate final cost, making this deliberate decision also reckless.
This type of technical debt is common in startups or small-scale companies, where the team might want to ship an MVP to raise funds or get a proof-of-concept out as early as possible. In that scenario, a team might know about good design practices but decide to follow a "popsicle sticks and duct tape" approach because they think they can't afford the time required to write clean code.
Even though the tech debt was intentional, and the team might be able to achieve their goal and stick to a tight deadline, this approach has poor results and can become an unsuccessful strategy for the software in the long run.
Deliberate and prudent
Like the previous type, the deliberate and prudent technical debt happens when the team knows that a decision will cause tech debt but moves forward anyway. But unlike reckless debt, in this case, the decision is made after analyzing all the consequences. The team decides the debt is acceptable if the payoff for an earlier release is greater than the cost of the technical debt.
In this type of technical debt, the team analyses the risk and creates a plan of action to carefully and effectively handle the consequences of the tech debt, reducing the harm to a minimum. They also define a plan to pay off the debt.
Once the organization achieves the goal or meets the deadline they were aiming for, the team goes back to fix all the issues, refactor the code, and apply best practices.
Inadvertent and reckless
Inadvertent and reckless technical debt is the most harmful type of debt. It happens when the team doesn’t have enough experience and blindly implements a solution without realizing they’re getting into debt.
A common situation is when an organization lacks human resources and needs to ask for inexperienced or non-professional developers to implement the software. As a result, the team will write low-quality code and generate technical debt. Recklessness or lack of knowledge can lead to unwanted issues which more experienced developers could easily avoid.
Due to their lack of skills, those inexperienced devs are unaware they’re causing tech debt. So it is almost impossible to plan solutions or accurately measure the negative impact of the debt. The best way to pay this type of technical debt is to hire more experienced developers to analyze and rewrite the code.
Inadvertent and prudent
Inadvertent and prudent technical debt happens when a knowledgeable team applies best practices during the software development but inadvertently generates technical debt due to unseen coding mistakes. However, the team can identify and pay the technical debt later on due to their skills.
This type of technical debt is related to learning and innovation. For example, when a developer is coding, they are learning. After some time of finishing a piece of software, a developer can understand how to implement a better solution. The developer can then take action and improve the code.
[Talk] When Technical Debt gets in the way of growth
Would you like to hear an expert panel dive deeper into the topic of Technical Debt? Join Codacy CEO, Jaime Jorge, in an exclusive talk with Tim Cochran, Technical Director at Thoughtworks, and Carl Nygard, Technical Principal at Thoughtworks. We’ll cover:
- What is prudent vs. reckless technical debt;
- The importance of addressing technical debt;
- What are signs that software quality is deteriorating that scaling companies should be looking for?;
- How should we address technical debt; and much more!
Join us in our Talk When Technical Debt gets in the way of growth. See you there!
👉 When: June 21st 2022, 4 pm UTC / 11 am CDT
👉 Where: online - registration needed