Tim Bull posted a fantastic comment on my last post about Technical Debt and I thought it would be good to share it again broadly here.
“There’s a third category of technical debt which is subtly different. Decisions that are made knowing that there is a better solution, but that the business stage or problem doesn’t validate that level of effort yet.
I think this is increasingly common in Lean Startups, where you do the minimum to validate the idea, but you are often left you with Technical Debt (we know this won’t work when we get to 100,000 users, but it’s fine for 1,000). You know there is a better solution, but you trade speed and validation for future benefit.
You’re spot on when you say that it’s the ability to pay it down that matters – like with all debt really. Technical debt isn’t inherently bad, but if you take on more than you’re ability to repay it in the future you’re in trouble!”
Yesterday, Alex talked about a government that was continuing to use a traffic model created in the 70’s to plan their roads and new infrastructure build. Besides the point that it’s not really very lean to be still using a template from 40 years ago to define today’s new roads (!) but I also feel comfortable saying that’s a direction that should have been pivoted a long time ago. However, the government had sunk a significant cost into creating said new roads.
Has anyone heard of any organizations out there, not working with code, that have been working in a more agile way to pay back their debt/sunk costs?