Technical debt is a hot topic among agilists. What is it? Does it really matter? Is it a problem? Should you be concerned about it?
Let’s start with a definition of technical debt. It occurs when development teams cut corners to meet deadlines. Let’s be honest, we all take liberties to meet scheduled commitments. When we do, little things remain — let’s say — less than perfect.
Technical debt can occur in many forms:
- Stories left partially unfinished
- Software architecture that is inelegant at best and sloppy at worst
- User interface design that is confusing
- Source code that is inefficient and bloated
- Test cases that are incomplete
- Documentation that is terse and misleading
Okay, so none of these sound like good engineering practice, do they? Regardless, some aspects of technical debt will occur on every project.
Does technical debt really matter in agile software development?
Some debt is okay. Most of us have monetary debt of some kind — education, car, house, credit card, etc. As long as we maintain control and don’t let it grow too large, debt is a good thing. It gives us leverage and helps us enjoy life.
Technical debt is similar. There will always be some. We just need to keep it controlled.
Be aware that some technical debts are more significant than others. For example, if you have a code module that is poorly implemented, you are in debt. If the code module is heavily used, the debt will have to be paid, that is, the code will have to be refactored. However, if the code module is only rarely used, why spend the time to refactor it?
A similar argument can be made about any of the aspects of technical debt listed above. If it’s important, pay off the debt by refactoring, cleaning up or completing the artifact. If it’s not important, ignore the debt or only invest enough time to reduce the debt to a tolerable level.
Stay in control. Take on technical debt during the project in a measured and disciplined manner. Pay it off as needed. Make sense?