Technical Debt vs. Product Debt
by Antony Marcano, with Andy Palmer
Technical Debt is a term coined by Ward Cunningham to convey the consequences of compromises on ‘internal quality’. Compromises that gradually slow the pace of development. We have seen this mis-applied to compromises in ‘external quality’ — externally visible compromises we’ll call ‘Product Debt’ for now. These are the known defects; the usability compromises; the less-than-ideal performance of the product.
Think of Technical Debt as borrowing from future speed of delivery in order to deliver faster than the future, today. It’s the code we end up with when we quickly hack something in, to get it working; maybe just enough refactoring to reflect our understanding but not enough to make it easy to change… and we leave it that way (for now). Maybe we didn’t do TDD; maybe we didn’t break that class/module apart; maybe we didn’t abstract where we could; maybe we wrote tests at too high a level, slowing the execution time of the tests.
These compromises on ‘internal quality’ will make it harder to add the next change and harder again for the change after that. Instead of the cost-of-change remaining flat, it begins to increase, much like accruing interest. This may be debt worth incurring if the cost of delay today exceeds the value we’d gain from delivering faster tomorrow.
Product Debt is distinct from Technical Debt. ‘Product Debt’ is that defective behaviour we knew was there but had a workaround for; that irritating extra few clicks needed for the user to get to the thing they do most often; the performance of the app that causes user-tasks to take longer; the restart they have to do every few days.
These compromises in ‘external quality’ are often decisions made by the more business focused members of the team. You might do this if the cost of delay exceeds the brand-damage and commercial losses from these externally visible quality issues. These become items on our product backlog, borrowing capacity from our focus in the future.
Technical Debt: Compromises on internal quality — expediting release today; borrowing speed from our pace of change tomorrow (longer time per change);
Product Debt: Compromises on external quality — expediting release today; borrowing capacity from our focus tomorrow (greater quantity of change).
We sometimes see these concepts lumped together under the banner of technical debt, resulting in problems. One problem we’ve seen, among others, is that the business believe that this ‘technical debt’ should be on the product backlog to be prioritised by the business (there are good arguments against having technical debt on the backlog). A consequence of this is that the real Technical Debt, the internal quality issues, just never get any attention and the speed at which we can move continually worsens.
Let’s not think of debt as a bad thing… It is perfectly acceptable, even desirable, if it allows us to exploit an opportunity sooner. The interest we incur becomes an investment that can yield greater value than it costs. When we make these decisions consciously, knowing exactly where we are borrowing from, we give ourselves a better chance of generating a positive return on that investment.
How does Product Debt differ from Product Inventory? Read more…
Experts disclaimer: If you’re reading this and thinking “no, ‘Product Debt’ isn’t a good label; both internal and external quality are integral to the product as a whole”, we agree. If you have a better label, than ‘Product Debt’, that will get this across and help product managers, product owners and business stakeholders see the distinction, do let us know.
Explore ways you can unlock similar insights by contacting us via RiverGlide.com
