Dealing with Technical Debt cuts to the heart of the 'debt' metaphor's limitations. Debt implies regular interest payments, but that's not necessarily the case with technical debt. There's quite a continuum, from your 'high street bank' style debt: obvious, regular 'payments' impeding forward momentum; to your loan-shark style debt: maybe you'll get away without paying anything for a long time, but one night in a dark alley he'll want your kneecaps. This latter, unpredictable impact, is the more common scenario.
This then clarifies our approach towards technical debt: treat it as a risk. So, like all risks, you can:
- Mitigate - Have a fall-back position if the debt becomes an issue
- Accept - Assess that the risk is lower than the cost of fixing. You might get lucky
- Reduce - Either deal with the debt, or avoid building new functionality on debt-ridden areas
- Transfer - Make it SomeoneElsesProblem. Tricky.
Posts
2 comments:
I really like your Technical Debt posts. It's put into words pains i've felt in every gig and never had the proper terms to express.
The most common way of dealing with Debt I've seen is the "write the next version from the ground up". And usually, by the time that option gains traction it is the only viable method to dealing with the debt ridden codebase currently in place. But it sure is expensive and time consuming. It never gets spec'ed out exhaustively and so it's prone to project overruns to the point where the re-engineering project becomes bogged down in keeping up with the debt still being accrued on the old code base.
Another thing I've seen plenty of is the "let's build it so that it's expandable" with stubs and placeholders that may never get implemented or are not needed as the business rules change. This becomes instant legacy that you are afraid to remove, because you can't figure out why it was created.
Keeping it simple seems like the best policy, but when a design decision is simple vs. inflexible is a constant struggle to evaluate.
Yeah, it's hard. But if simple vs inflexible was an obvious choice, I'd be out of a job.
I've put some thoughts into when to do a re-write in the next post.
Post a Comment