One of the greatest gifts the agile movement has given us is to quantify something we’ve been ignoring in software development for the last 50 years. That is, the notion that software degrades over time, it ages, and it needs ongoing maintenance to keep it viable. That idea is Technical Debt.
Most developers have known that for that same number of years. That no matter how well something is designed, it won’t stand up to real-world usage for 2-5-10+ years without a significant investment in rework and redesign. The agile community has coined a term for that as well—refactoring.
The unfortunate part is that many organizations, leaders, and managers refuse to acknowledge, invest in, or plan for this ongoing maintenance. I don’t know why. Perhaps nobody has the courage to actually say—the original investment was simply the beginning or to say—“No” to “new features” in lieu of refactoring. I will grant you that as a stakeholder I never really enjoyed paying this cost. I’d much rather accelerate towards new features. But sometimes as a leader you have to have the courage to face reality in your decision-making.
Anyway, I want to share a few resources around Technical Debt for you here so that you can do some homework in understanding and defending against it:
- I love this article –
And there’s the book by Chris Sterling that focuses entirely on Technical Debt. The title is . It’s a wonderfully broad and deep treatment of this topic and I’d recommend it.
Technical Test Debt
Finally, I’ve extended the Technical Debt term a bit to cover testing constructs and artifacts – calling it Technical Test Debt. I feel the term should be more broadly applied than simply “to the code”. Here’s an I wrote in 2012 for Testing Experience magazine. If you’re a tester or simply an agile team member, I’d highly recommend reading it to help (again) broaden your views towards Technical Debt.
I hope this short post has reminded you of the import of being proactive with Technical Debt in your software contexts.
Stay agile my friends,
Bob.