The idea of technical debt is a fairly old one in engineering circles and it has enormous relevance to the way we solve business problems in organizations today. This came up over a coffee discussion today with Alex Steffens and Ross Hill. We discussed the problem of getting people to change a decision, or create a new solution, when there was already a sunk cost that had been invested in said solution. The idea of sunk cost, seemed to overlap heavily to the idea of technical debt.
Pete Yandell once walked me through how he defined technical debt, and I’d like to share that here today.
Technical debt is essentially the idea that once you release a piece of work, it has a number of flaws in it which require maintenance. This is true of everything in an organisation, regardless of whether what they are doing is code based or not. The key is not how you eradicate technical debt, but how you actively maintain it and pay it down..
There are two main types of technical debt:
1) Debt is accrued through poor work and/or poor decisions made in the present day, given the best present data.
The debt is accrued through poor decisions and poor execution at the time of deployment. This might be someone producing work that’s not up to scratch, or just a group of people making a decision which is not ideal even in the current time.
2) Debt is accrued over time, as a decision that was correctly made years ago becomes less correct as new solutions and opportunities appear.
Pete explained that, as an engineer, he had the chance to pay down some debt and make his code better each time he produced some new code. In an agile world, organizations produce new work in a consistent pattern. If that’s the paradigm that an organisation runs by, then whenever new work is created there is also a new chance to pay down some of the old debt that exists – be that type 1 or 2 above.
And so, we are seeing many organizations moving closer towards a more agile way of practicing business. This will have great ramifications when the world is faced with making decisions where sunk costs are present, which need to be reversed because it gives people a guided way to pay the dent down gradually – rather than in one big, expensive hit
The Squiggly Line 
Interesting perspective!
It does imply that the ‘debt’ is defined relative to some sort of a state of perfection though which may be a bit problematic… it would be easy for the less disruptive to say “well it ain’t broke, so there’s no debt, so no need to pay anything down” aka change.
Also I see ‘(link)’ halfway down the page.
Thanks for pointing out the (link). I posted this one from an email which I intended to link up. I’ll amend it 🙂
Interesting perspective!
It does imply that the ‘debt’ is defined relative to some sort of a state of perfection though which may be a bit problematic… it would be easy for the less disruptive to say “well it ain’t broke, so there’s no debt, so no need to pay anything down” aka change.
Also I see ‘(link)’ halfway down the page.
Interesting perspective!
It does imply that the ‘debt’ is defined relative to some sort of a state of perfection though which may be a bit problematic… it would be easy for the less disruptive to say “well it ain’t broke, so there’s no debt, so no need to pay anything down” aka change.
Also I see ‘(link)’ halfway down the page.
quote … “Technical debt is essentially the idea that once you release a piece of work, it has a number of flaws in it which require maintenance”
this is a perfect description of human life on earth …
life or code, the solution is the same .. get to a more fundamental level .. equivalent to more subtle … whether consciousness or system.
Thanks Greg, I agree. It’s going to an enjoyable time helping to reshape our organisations to reflect this reality.
I guess if you look at this from the other side of the coin it supports enabling innovation, comfort with change, agility, early awareness of opportunities to optimise. In other words disciplined approach to continually looking for the Better View of the Situations and working towards it. I do wonder if this is taken to an extreme at what point there might be a diminishing return for these efforts, particularly if working towards “perfection”. ie 80:20 rule.
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 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 your ability to repay it in the future you’re in trouble!
Thanks for the comment, Tim! So very well said.
I’m keen to see how the application of #leanstartup principles apply in a non-technical situation. 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.
How do we encourage organizations, often with multiple millions of dollars ‘sunk’ into one direction, to embrace those ideals of the #leanstartup to pay down their debt as they also build new features? Is there anyone doing this today?