Technical Debt
Learn about how Agile teams manage Technical Debt.
Browse topics
When you first hear the term “Technical Debt” in the Agile context, you may not immediately understand how this financial term relates to Agile software development. It is ok, no worries.
When it comes to software development, Tech Debt (or TD) means that certain necessary work gets delayed during the development of a software project to hit a deliverable or a deadline.
TD is the coding you must do tomorrow as you took a shortcut to deliver the software today. In this post, we give a Technical debt definition and take a deep dive into the concept of TD, exploring many related topics as well.
What Is Technical Debt?
Technical Debt describes the situation when a development team speeds up the project delivery that will require refactoring later. The term is also known as tech debt, design debt, or code debt. This is about when a quicker development process becomes the priority instead of high-quality code.
The Technical Debt metaphor is used in the technology space all over the world. It includes a catchall that covers everything from bugs to missing documentation and legacy code.
However, why do we call it that way? In order to understand this, we should learn about the roots of the concept.
Where does the concept come from?
One of the authors of the famous Agile Manifesto, Ward Cunningham, once compared some problems with code with financial debt. He said that it is ok to borrow against the future, as long as you pay it off. The author titled it “Technical Debt”, and this metaphor has gained momentum.
The main concept determines a serious problem that many software teams strive to manage. Ward Cunningham used it when he was developing a financial app in Smalltalk. The financial analogy was used as he wanted to justify to his boss the refactoring they were doing.
In 1992, he provided additional details saying that shipping first-time code is like going into debt. Development can be increased by a little debt so long as it is paid back promptly with refactoring. And when the debt is not repaid, danger may occur. Interest on that debt is minutes spent on code that is not quite right for the programming task of the moment counts.
When delivering code that is not right for the programming task of the moment, a development team incurs Technical Debt. It significantly decreases productivity, and such a loss is the interest of the Technical Debt.
Why this metaphor got popularity
The Tech Debt concept is a good way to communicate the need for refactoring and improvement tasks related to the source code and its architecture.
If you can approximately estimate the time needed for fixing what is not right into your code, the principal of your debt, you are able to compare this info with the other project data. With this estimation, you will understand the overall situation and plan repayment activities.
Applying Tech Debt in Scrum/Agile
The Scrum framework has become extremely popular for software developers who try to deliver their products in a more efficient manner.
Scrum has set principles, and one of them is that things are unpredictable: your clients change their minds, and new needs arise often. The openness to changes means that Technical Debt will likely occur when using Scrum.
Two types of Tech Debt in Scrum can be defined:
- The active choice is to create a short-term solution that contains less-than-perfect code to let you deliver the product faster. It is expected that the dev team will go back and improve the code quality after the release.
- The other Tech Debt happens more passively as developers discover more valuable info about the problem they’re trying to solve. As new needs arise, solutions that have worked recently may not work in the future. The code requires adjustment and refactoring. This contains a certain amount of debt.
By the way, the Scrum Guide does not provide specific guidance regarding Technical Debt. However, accruing this debt is an essential part of the business, so teams should try their best to handle their code-based financials better.
How to handle it?
In order to handle it, Scrum teams should:
- Prioritize transparency with Tech Debt. This is what makes managing technical debt much simpler. Visualize the technical debt to keep it as a front-of-mind priority and review it during every Sprint meeting.
- Monitor the debt. It is a good idea to count bugs and use more in-depth code metrics if possible.
- Pay back debt regularly and quickly. Like with financial debt, it is better to manage technical debt when teams pay back their loans regularly.
- Align product backlog. It should contain the tasks related to paying back Technical Debt.
- Change the Definition of “Done.” Do not count something as finished until it meets a standard for manageable technical debt.
- Standardize procedures. Generate a formula for how your team handles adding new features that include the introduction of tech debt.
Types of Technical Debt
People often argue about the differences of Technical Debt as it can take on various forms.
There are two obvious types of Technical Debt: intentional and unintentional.
- Intentional TD can be also called deliberate or active. It occurs when companies choose to leave room for improvement in their code for the sake of reducing time-to-market.
- Unintentional TD is also called outdated, passive, or accidental. This type of Tech Debt happens when the code quality needs improvement after a period of time. It can be the result of weak production the first time around or simply the natural need for updates when code becomes outdated.
In 2014, the authors of “Towards an Ontology of Technical Debt” proclaimed that companies would be better served if their Tech Debt had more specific categories. So, they proposed 13 types of Technical Debt. Each type includes the specific problem within the title. Here they are:
- Architecture Debt
- Build Debt
- Code Debt
- Defect Debt
- Design Debt
- Documentation Debt
- Infrastructure Debt
- People Debt
- Process Debt
- Requirement Debt
- Service Debt
- Test Automation Debt
- Test Debt
All these types have their own specifics but the most famous way of categorizing TD comes from the Technical Debt Quadrant.
What Is the Technical Debt Quadrant?
In 2009, the twofold separation of intentional and unintentional technical debt was nuanced by Martin Fowler.
Like Cunningham, Fowler was one of the 17 authors of Agile Manifesto. He understood that people used the metaphor of Tech Debt to ask the wrong questions.
Instead of digging out the answer to tech questions about design flaws, Martin strived to know if the debt these software systems accumulated was reckless or prudent. This distinction and the idea of deliberate/inadvertent debt formed the basis of the Technical Debt Quadrant.
This quadrant creates four types of Tech Debt:
- Reckless/Deliberate
- Reckless/Inadvertent
- Prudent/Deliberate
- Prudent/Inadvertent
Is it easy to realize the difference between the prudent and the reckless?
The prudent team understands the moves they make and use their Technical Debt intentionally.
The reckless team uses their software system like a cardholder during shopping, and the debt just keeps coming.
Technical Debt Metrics: How to Analyze TD?
If you cannot measure Tech Debt, then knowing a lot about the debt does not really matter. As with any effective management plan, companies need to know the best metrics to gain control over their TD. Here are some of the most efficient metrics:
1. Bugs
Developers should count and keep track of their bugs at least. This includes fixed and unfixed bugs. Noting the unfixed bug lets software developers fix them during their Agile iterations. Catching the fixed bugs allows them to measure how effective their TD management process is.
2. Code quality
While bugs directly affect software end-users, code complexity can damage the development team and the entire company.
It’s better to consider such code complexity metrics as cyclamate complexity, lines of code, class coupling, the depth of Inheritance, etc. The lower each measure is, the better.
3. Code cohesion
Intensified focusing on code cohesion will make the code less complex in the end. High code cohesion typically means that the code is more reusable and maintainable. It also minimizes the number of people involved in coding.
4. Code ownership
More engineers mean more cruft. More cruft may lead to greater problems and higher levels of unintentional Tech Debt.
This metric allows project management to see the number of people working on different code pieces.
5. Churn
Code “churns” appear when code gets replaced or rewritten, for example. It is important to pay special attention to code that is extremely active because any problem in there will be exacerbated.
Measuring churn will you help to recognize and prioritize what parts of the code require refactoring. If there is a need to constantly address bugs around the same part of the code, then something is going wrong over there.
How to identify Technical Debt
Some warning signs demonstrate that your project has created Tech Debt:
- When code seems much more subtle than logic errors. It indicates problems that are more likely to impact overall performance quality than cause a crash.
- When the product has bugs that will cause an entire system crash.
- When there are higher complexity levels (when technologies overlap each other).
- When there are issues with a coding style that can be handled by developing a coding style guide and sticking to it.
- When there are non-functional requirement issues where the code violates an NFR restraint.
When you leave these essential things unaddressed, it can result in:
- Reduced agility
- The higher total cost of ownership
- Negative customer experience
- Longer time to market
- Poor security
Good and bad reasons for Tech Debt
Like financial debt, there can be good reasons for TD. However, it is important to know that going in, so debt does not get ahead of the team, slowing down progress and future deliveries.
Delivery is more important than internal code cleanliness, and it is an essential reason for incurring Tech Debt. When the product works for the user (despite not being the best or the cleanest one), then delivery can bring the company a lot more in terms of revenue and time to market than what they lose in code perfection.
A bad reason for holding TD is when the team chose to focus on other areas that can be more innovative but less important.
Development teams must be balanced. It is important to look at many sides of the issue to define how much Tech Debt is fine.
What Are the Best Practices in Managing Technical Debt?
There are some reliable ways to manage Technical Debt:
1. Assessing
The process of identifying TD may be accompanied by some key signals. For example, the performance ratings of the product can be reduced or developers can need much longer to iterate. How to measure this? What is the real cost of Tech Debt?
To measure TD, you can look at the number of days developers would need to spend reducing TD by performing activities like refactoring or replacing the app. After attaching a dollar amount to these functions, you may compare this data to other milestones, (for example, the number of remaining days before the release date). It will help you to make your cost/benefit analysis more effective.
2. Communicating
It is also crucial to understand that TD exists in the first place and share that discovery with the stakeholders. IT management should communicate to non-IT managers about the true cost of Tech Debt. And the head of IT should be responsible for explaining the importance of paying down Technical Debt sooner than later.
3. Paying off
You can pay Technical Debt using one of the following options:
- Completely waive the requirement. It means the company decides to live with the system as it is and no longer considers the requirement necessary.
- Refactor the app. This is about reducing complexity, removing duplicates, and improving the structure of the code.
- Replace the app. This will probably lead to a new TD, but the idea is to address it quickly and minimize it.
How to minimize Technical Debt with Agile practices?
The term “done” is quite relative, and every Agile practitioner knows that. In traditional development, the software is done when it is delivered to end-users. However, in Agile, work iterations are frequently delivered to users, improving issues and bugs that develop in each release. So, there is no “done”.
Instead of promoting multiple functions in a release, Agile assumes reducing the scope of a release to ensure quality work. It embraces iterations and increments instead of finished projects, that is why implementing Agile theories can be a great way to stay on top of Tech Debt.
IT teams think in short bursts of work, and this helps them to tackle smaller groups of TD continuously. Therefore, Debt is not forgotten for bigger projects and phases as well.
Conclusion
Changing the philosophy of your team on how to manage Technical Debt isn’t easy. Sometimes companies need to cut development time short in order to get to market sooner. With that in mind, educate your product owner on the real cost of TD, modularize your architecture, and write automated tests.
Remember that Tech Debt is a reality for all software teams. No one can avoid it entirely. The key thing is to keep it from spiraling out of control.