It's a great analogy, and it reminds me of a model I like to use when thinking of technical debt:<p>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.<p>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.<p>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.<p>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).
I recently needed an HDMI cord for a monitor and realized that my cord drawer was accruing technical debt.<p>Whenever I am done with a cord I just throw it in there... it gets all tangled up with all the others. When I inevitably need one of those cords I impatiently pull it out and it makes all the other cords more tangled.<p>Here I am needing an HDMI cable that won't just come out easily, I have to pay off my past laziness. But I have choices/tradeoffs/opportunities here.<p>I can just hurry up and get the minimum untangled and get back to watching TV.<p>I could untangle all of them since untangling one of them will help me untangle the others and wrap and label them.<p>I could just untangle the minimum, but also throw a roll of tape and a marker in there and wrap and label all future cords that go into that drawer, eventually they'll all be nicely wrapped up and well documented.<p>¯\_(ツ)_/¯
I like the analogy, but it slightly suggests that you're always powerless along the way and that the debt is inevitable. I think there _is_ a technique that is possible in a lot of situations: not putting in abstractions/complexity that don't really do any of transformation/transfer required of the underlying requirements.<p>The reason why this is often possible, is that it's _less_ work to start with compared to adding in the layers...<p>... and then when unexpected requirements turn up, there is less complexity to deal with, there are fewer layers to work/hack around, and refactoring those that _are_ there to be more suitable to the current set of requirements is often easier, and so more likely to fit into time constraints.<p>I like to think of it as:<p>> Just about everything is cheaper than the wrong abstraction<p>(With a clear nod to Sandi Metz)
One thing I like about this analogy is the implication that some debt can make it harder to pay off other debt. It definitely operates in higher dimensions than just the two. I'm not sure about the implication that delivered features don't have a cost.
Is tech debt subjective? I've worked on different teams that call anything from wrong grammar in comments to incorrect capitalization of a var name tech debt. Wondering if it follows that more code = more debt because more people have opportunities to disagree about how something was done.<p>Asking for a friend.
This might be captain obvious to some, but I think it still needs to be said: Technical debt is like any other debt and needs thorough analysis and some business strategy applied before things can and do get better.