Organizations often accumulate technical debt as the pressure to deliver customer value quickly increases, systems grow, and extending functionality the right way becomes more difficult.
Technical debt refers to the costs incurred when shortcuts or suboptimal solutions are implemented during software development, resulting in future challenges and maintenance issues. Managing technical debt is crucial for maintaining a high-quality software system that is scalable, maintainable, and reliable.
In this article, I will explore practices for managing technical debt in software development, providing insights and practical tips for controlling the amount of technical debt your team is taking on.
Understanding Technical Debt
Technical debt can manifest in various forms, such as outdated code, inefficient algorithms, and inadequate documentation. It can accumulate over time due to tight deadlines, lack of resources, or changing business requirements.
Like financial debt, technical debt accrues interest in the form of increased maintenance efforts, reduced effectiveness and productivity, and higher risks of system failures. Understanding the different types of technical debt and their implications is essential to manage and mitigating them effectively.
It is essential to understand that technical debt is nothing wrong per se. Taking up technical debt is like taking a loan: It can help you to achieve specific short-term goals faster. However, there is accumulating interest on the debt you are taking. You need to pay it back, and it will get more expensive if you postpone repayment for too long. Therefore, it is crucial to be mindful of the technical debt you are consciously taking. Furthermore, you need to keep an overview of the technical debt you are taking and the cost that comes with it in terms of reduced speed, increased risk of bugs, and required time and money for managing and reducing it.
Types of Technical Debt
1. Design Debt
This type of technical debt occurs when software is built with suboptimal design decisions or lacks proper architectural considerations. It can result in a system that is hard to understand, modify, or extend, leading to increased maintenance costs and reduced agility.
It is essential to note that designing systems is not a one-time effort. As we learn more about the context of an application, the design needs to evolve, too. Therefore, teams often accumulate design debt later on as they don’t refactor the system design to suit the context they discover.
The problem with this type of debt is that it can be tough to remove and notice initially. Often, this type of debt comes from something other than conscious decisions but rather from accidental complexity and not reflecting on the system design enough. (More about this in the section “There is more than technical debt”)
2. Code Debt
Code debt refers to poorly written or outdated code that is difficult to maintain or enhance. It may include duplicate code, complex logic, or deprecated technologies, negatively impacting system performance, stability, and maintainability.
Teams can also accumulate code debt by deciding on new code styles and not changing their entire code base to reflect that new style.
It is also noteworthy that duplicate code can be good in some cases. First, if different teams own parts of the system or the code belongs to other services, duplication can reduce dependencies and, therefore, even make it easier to maintain the code. Avoid falling into the trap of removing all duplication. Read more on this in “DRY — DO Repeat Yourself”.
3. Testing Debt
Testing debt arises when good testing practices are not followed during software development. It can lead to undetected defects, low test coverage, and increased risks of regressions, resulting in higher costs and a longer time to market.
Testing debt is particularly harmful because it makes practices of highly effective teams, such as continuous integration and deployment, nearly impossible. Bugs in production will happen often and force teams to switch contexts and find quick fixes for those bugs.
Testing debt also leads to the accumulation of other debt, such as code and design debt, as teams won’t feel safe to refactor the code base if there are no proper tests. In such a context, bugs will usually be fixed by the smallest and easiest change possible, even if that leads to a less maintainable design.
Therefore, I recommend investing in proper automated tests and testability on all system levels. The only exceptions for me are one-off scripts or prototypes that are tested manually and not maintained or evolved but thrown away.
4. Documentation Debt
Documentation debt occurs when documentation is incomplete, outdated, too much, or not aligned with the software system’s current state. It can hinder effective knowledge sharing, collaboration, and system understanding, leading to decreased productivity and increased risks of miscommunication.
Teams accumulate this type of debt automatically over time if they do not have proper documentation processes.
First, we need to remember that documentation comes at a cost. The more documentation you need for your system, the more expensive it gets. It takes time to write, maintain and also read and understand that documentation. Therefore, the first approach should always be to avoid unnecessary documentation and make the system easier to understand.
Second, it can help review and update the documentation regularly. At BRYTER, for example, the Developer Experience team built a bot that would automatically notify teams in Slack if some of their documentation in Notion was not updated for more than four weeks. This reminded teams to check that document and edit or delete it if it was outdated.
Practices for Managing Technical Debt
1. Proactive Planning
One of the critical practices in managing technical debt is to adopt a proactive planning approach. It involves setting up a clear roadmap and prioritizing technical debt items based on their impact and urgency. It is essential to include stakeholders, including developers, testers, product managers, and others, in the planning process to ensure a shared understanding and alignment on the technical debt management strategy.
It is crucial that not only developers understand and know about the technical debt but that it is made visible and understandable to product managers and other more business-focused people. Technical debt can become a significant business risk often overlooked by non-technical folks. Therefore, it is the responsibility of engineers and especially technical leads to make the debt and its cost and consequences visible to the business.
Technical debt items need to be as much included in quarterly plannings, sprint plannings, or whatever else your team is using to plan their work, as features and other requests coming from the business.
At BRYTER, the tech leadership community would maintain an overview of the well-known tech debt items, upcoming deprecations, and the like and discuss their priority with the product leadership community. For quarterly OKR planning, we would make sure, that also purely technical objectives would be considered. This helped to not overfill quarters with ”feature”-objectives. It made the importance of technical investments visible and understandable to the business.
2. Continuous Monitoring
Regularly monitoring the software system for technical debt is crucial for identifying and addressing potential issues early on. This can involve conducting code reviews, static code analysis, and automated testing to detect code smells, design flaws, and other technical debt.
Monitoring can also involve gathering feedback from end-users, support teams, and other stakeholders to identify pain points and areas of improvement.
Metrics that represent how quickly engineers can add new features to the system, how quickly they can fix bugs, how fast they can deploy changes to production, and how often incidents happen can shed some light on the situation.
Even the DORA metrics can reveal increasing technical debt. If, for example, the lead time for changes and the change failure rate go up, this can indicate a system that got harder to maintain. This signals that it is time to find and reduce technical debt and other unnecessary complexity.
3. Incremental Refactoring
Refactoring is improving software’s internal structure and design without changing its external behavior. It is a powerful technique for managing technical debt, as it helps gradually pay off the accumulated debt while keeping the system functional.
Incremental refactoring involves making small, focused changes to the codebase to address specific technical debt, such as removing duplicate code, simplifying complex logic, and improving test coverage. It is crucial to prioritize refactoring efforts based on the business value, risks, and dependencies to achieve maximum positive business impact.
Ideally, most refactorings happen during day-to-day work on the system. Whenever the team discovers an area that would benefit a refactoring to match the style guide or simplify the introduction of a change, the team should do this. There should be no need for additional planning, tickets, or approval from other instances. Improving the system while working in it means doing your job as an engineer in the best way possible. You should not need permission for that. The same goes for adding tests when we discover that they are missing. A great approach to every change in a system is:
- Add a test to make changing the system safe if such a test is missing.
- Refactor the system to make the change more straightforward.
- Change the system to do what it should while adapting or extending the tests to reflect this.
- Refactor test and production code to be clean, understandable, and maintainable.
- Check if any documentation can be removed, needs to be updated, or must be added. (Ordered by decreasing preference)
4. Collaboration
Teams often accept technical debt because they discover it only when it is time for a huge code review. In that case, the effort of changing something feels too big and it is tedious to mention all the issues with a pull request. Reviewers might be inclined to accept a change, even if there is a better solution. The best way for teams to avoid this situation is to collaborate on writing the code.
Team programming, ensemble programming, and pair programming can help prevent technical debt in the first place. When a group of people is developing code together, it is easy to raise concerns about missing tests, unmaintainable code, or violation of coding styles or agreed practices. Those concerns can be addressed by the group immediately. Furthermore, the group can find small, incremental steps to change the system and avoid massive, lengthy code reviews. Discussions about the best solution happen on the go and an immediate shared understanding of design decisions is formed in the process.
5. Documentation and Knowledge Sharing
Clear and up-to-date documentation is essential for managing technical debt effectively. Documenting the system’s architecture, design decisions, coding standards, and other relevant information can help understand and maintain the software system.
Properly documenting design decisions and their context enables people to change the design later. It allows them to understand if the context might have changed and if the chosen architecture is not suitable anymore. Lack of documentation, such as architecture decision records (ADRs), can lead to resistance to change something because people need clarification about the reasons for a particular design.
Additionally, promoting a culture of knowledge sharing and (again) collaboration among team members can facilitate effective technical debt management. Encouraging pair programming, cross-team communication, and regular code reviews (as a last resort) can help identify and address technical debt items more efficiently.
6. Tools and Automation
Utilizing tools and automation can significantly aid in managing technical debt. Static code analysis tools, unit testing frameworks, and code review tools can help identify and address technical debt items more effectively.
Statical code analysis tools and linters often are not only able to highlight code style violations or unsafe code but are also able to suggest and apply fixes (semi-)automatically. Therefore, it is easier to adopt new code styles by automatically changing the code base to match.
Automation can also be used for building, testing, and deploying software, reducing the chances of introducing new technical debt. Additionally, using version control systems and configuration management tools can help track changes and manage different versions of the software system, ensuring proper documentation of the “Why” of changes and reducing the risk of technical debt accumulation.
7. Training and Skill Development
Regular training and skill development opportunities for team members can contribute to effective technical debt management. Keeping up-to-date with the latest technologies, practices, and trends can help prevent technical debt from accumulating.
Encouraging continuous learning and professional development can empower team members to proactively identify and address technical debt, resulting in a more robust and maintainable software system.
There is more than technical debt
Strictly speaking, as mentioned at the beginning of this article, technical debt is something that software teams take on consciously to move faster in the short term. However, as mentioned in some sections above, there is more than this clear and structured approach to taking debt.
Software systems are like houses. When you build them, they are in sufficiently good shape unless you decide to take some shortcuts to finish them faster and cheaper. However, over time, they age, and things start to break and need to be renovated or replaced. The heating or the roof will break. As a homeowner, you must set aside time and money to fix those issues, or they will become more significant.
Software systems behave similarly. Without working on a system, its state gets worse. Frameworks and libraries become deprecated, and security vulnerabilities are detected and fixed in newer versions. Without addressing those issues, they become a massive risk for the system. Therefore, software companies need not only to manage conscious technical debt but also to keep a budget (time and money) to address these aging symptoms.
Furthermore, new technologies allow the software to be built better, improving speed, UX, and other aspects interesting for customers. Therefore, like a house on the real estate market, with modernization, software systems can become more competitive and relevant with proper investments. Think about CRM systems that used to be installed on a computer. Nowadays, if it does not run in the cloud or at least as a server-multi-client system, the vendor of such software is likely to be out of business soon.
To sum it up, more than technical debt is needed to remember. Even if companies could accurately decide about and measure the technical debt they are taking (realistically, often they are not), there will always be unplanned modernization and fixing work that must be considered. Luckily, like tech debt, those symptoms can be made visible and addressed in the same way as classical technical debt. They are ”debt from doing nothing”.
Conclusion
Managing technical debt is crucial for staying competitive and delivering high-quality software.
While this topic seems difficult to understand by business people, it is vital for the long-term business success of software companies. Therefore, technical leads and engineers must put effort into managing, visualizing, communicating, and reducing technical debt.
By adopting proactive planning, continuous monitoring, incremental refactoring, collaboration, documentation and knowledge sharing, tools and automation, and training and skill development, organizations can effectively manage technical debt and prevent it from becoming a hindrance in the long run.
Prioritizing technical debt management as an integral part of the software development process can result in a more reliable, scalable, and maintainable software system. Those systems enable organizations to deliver value to customers fast and with high quality. Furthermore, systems with low technical debt are often more enjoyable to work in. Thus, reducing technical debt also reduces the frustration of engineers and therefore churn.
I am curious: How are you managing technical debt in your company? Share your approach in the comments!
Is your team struggling with assessing, prioritizing, and removing technical debt? I can help! Schedule a FREE 30-minute call with me to discuss how to approach this challenge.
