Is your company drowning in debt? No, we don't mean the fancy fleet of cars that aren't paid for, or the new artwork in the lobby bought on credit-we're talking about technical debt. In this column, Johanna Rothman has a few tips on how to recognize technical debt in your organization.
Technical debt is the unfinished work your organization owes your product. It comes in varieties: requirements debt, design debt, and testing debt. It causes the developers to have trouble finding and fixing defects, and causes testers to have trouble knowing how and what to test.
You may be working in an organization where technical debt is an intentional choice, in exchange for gaining the benefit of time or resources. However, if the debt is hidden, by not collecting metrics, managers can play the "pass the hidden debt" game, hoping to drop it into someone else's hands before interest comes due. Keeping the debt visible helps keep the level of gaming down.
Recognizing Technical Debt
If you're a tester, how can you recognize technical debt? Look for indicators like these:
- As soon as the developers fix one defect, five more previously unknown defects pop up
- Testing time increases disproportionately to the development time
- Your developer to tester ratio is 1:1, and you still don't have enough testers because you're sure you haven't fully tested the product
- Developers start talking about re-architecting or redesigning the product. If the design debt is overwhelming, the developers start saying things like, "Nope, I'm not touching that. That's a feature, not a bug. If you want me to fix that, I'll have to re-architect the product"
- Developers refuse to touch a part of the product saying, "No one but Fred can touch that. I know Fred left three years ago, but no one else can work on it, because we don't understand it"
- Your developers threaten to leave because all they do is "maintenance"
- Developers and testers become experts at crisis management, spending more time supporting current customers—solving customer problems, fixing defects, verifying the fixes, and answering customer questions—than they spend developing and testing the product scheduled for release next month
- You're putting out point releases or patches weekly or daily
- You can't decide what not to test, because the risk of not testing everything, even for a point release, is too high
- You ship the product not because it's ready, but because everyone is too tired to continue the crunch mode you've been in
- You stop testing because you don't want to find more defects
- Your cost to fix a defect continues to increase, from release to release. (If you'd like to see a picture of this dynamic, check out Weinberg's Quality Software Management, Volume 4)