Technical Debt - How to manage it ?
What is Technical Debt ?
Technical debt is a concept in software engineering and there are many definitions out there, but in an essence it is software built yesterday that is a burden today. The software can be code, process, architecture, tool or documentation. We can use the financial debt metaphor to explain technical debt and it's the interest you pay for taking easy short term approaches over longer and right approaches.
Ward Cunningham coined this term in 1992 to explain refactoring while he was working on one of the products done using Smalltalk. This has gained steam in late 2000's with Tech industry growth and Martin Fowler defines it as build of cruft that makes it harder than it would ideally be to modify and extend the system further.
What incurs Technical Debt ?
Here are some ways that generally incur tech debt.
- Poorly written code and no adequate test coverage will make it hard for developers and future development.
- If we have code base worked by many contributors and often with in experienced developers and no proper code reviews, bad code can slip in contributing to tech debt.
- The other case is if we have systems or tools marked for deprecation and it lies out there rotten with bugs and no upgrades, causing a big tech debt.
- It can also happen in a natural process as the design and architecture evolve as it matures or if initial design is flawed to start with and you realized it when the system or soultion is put to work.
- Some times it can be on purpose and can happen with a conscious decision in the name of delivering the feature quickly or MVP (minimum viable product). It would be a byproduct of faster time to market by compromising to take short cuts instead of doing it in a right way.
What are the disadvantages of it ?
Like financial debt, there can be some serious consequences if we don’t pay back the debt.
- It could get in the way of delivering business features.
- If not managed properly it accumulates and becomes too much to bear, we have to carve out big chunk of time for refactoring it.
- It affects the productivity of teama and results in slower outputs with simple enhancement taking long time.
- It can impact reliability of the systems impacting business functionality.
Not all tech debt necessarily becomes a big problem and some times unlike financial debt, you don’t have to pay back. For instance, if the code base is never changed or touched in the future there is no point in fixing the debt.
How to manage and get rid of it ?
To manage tech debt we first need to identify it. There are some tools and indicators that can help in identifying it. Tools like Sonar can find code violations and code coverage tools can help in identifying it. If there are many todos and fixmes in the code or if the code is too complex to touch that it breaks many things, it is a pointer for tech debt. The other indicators are if a team is taking more time to deliver features with same team members over period of time, if we have a system, solution or tool that breaks in production too often or produces more bugs are all pointers for tech debt.
After identifying the debt, we need to quantify and size it with rough estimation of how small, medium or high it is in terms of cost and effort. All the size estimates should include priority, business impact and also take into account probability of code be read or changed in future. Here is a take at how we can size and address the debt.
- Small
- These are small things that developers are empowered to fix it when it is identified. It could be a linting issue, a more meaning full variable name, making the code more modular, adding more test cases. As Uncle Bob advocates - "Always leave the code better than you found it".
- Medium
- This type of debts might take a week or sprint worth of work to address it. If Agile is being practiced, we have to allocate some capacity for this kind of work in every program increment.
- Large
- This kind of debt is something that needs more time and cannot be addressed immediately. It could be something like a big architecture or design change, overhauling a system or a tool. This is where we need managers and leadership help to prioritize, fund, plan and keep it in check.
Conclusion
To get rid of technical debt you need commitment, discipline and perseverance. Everybody has a role to play in this right from developers, product owners to leaders. Developers should be disciplined to constantly refactor the code when they see debt in the code. Product owners should maintain the backlog of tech debt and ensure they are allocating capacity for clearing it. IT Leaders should have commitment and vision to set right priorities and allocate budget for this and they should be responsible for educating non IT leaders about problems with Tech debt. Also, keep in mind that tech debt is not a bad thing if it is managed properly and not all debt has to paid back.
Further Reading
https://martinfowler.com/bliki/TechnicalDebt.html
http://wiki.c2.com/?WardExplainsDebtMetaphor