| It's a great analogy, and it reminds me of a model I like to use when thinking of technical debt: Get a jar full of jelly beans, and every time you have to make a compromise (e.g. adding some hacky code or introducing some problem you'll have to fix later) take a bean out of the jar. If it's a terrible hack, then take out several. For the first few jelly beans, you won't even notice the change to the jar, and the first few compromises aren't going to be a problem for the code either. Once the decrease in the jar contents starts to become noticeable, though, use the fraction of empty space as an enlargement factor for any estimate. So if the jar is 10% empty, consciously and vocally add a 10% additional "interest payment" on every estimate you give. If the jar is half empty, then you can double your estimates. This is all very approximate and not rigorous at all, but it does help a team to visibly keep track of the amount of compromises they are making, and does surface the hidden cost to future development that gets ignored by a "normalization of deviance" bias. At the very least, even if a team isn't allowed to change their estimates based on this model, you still get to eat a jelly bean or two every time you add a hack to your code, which can make the decision less stressful (unless it becomes an incentive to deliberately add hacks). |
Realistically, something like 10-20% of the engineering resources at a company like Google or Microsoft are going to service technical debt at an institutional level. Sometimes it is literally all an engineer does, like maintain a deprecated system that can't be turned down for five years or a team migrating large systems from the old and busted to the new hotness, sometimes it's just the tax on engineers doing other projects to work around the technical debt. It's just what happens when you have tens of thousands of engineers working for decades.