Technical Debt Is Like Tetris

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).

We are, and it is.

>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.

That's no good, because we can pile debt even when we don't put in "abstractions/complexity" that are not required.

Plus, the abstractions we built (that were 100% necessary) 1 year ago, can impact a big debt into the requirements we have now.

Debt comes from (a) the mismatch between the cleanest/fittest implementation and what we have done instead (which would always be there), (b) things set rigidly, even if they were OK for then (c) changing requirements that force us to work around our imperfect and rigid implementation.

So, it's multifold:

1) We'll never be able to write the cleanest implementation (due to time/skill/etc. constraints)

2) Even if we get close to the cleanest implementation, we'll never be able to foresee all kinds of future needs (and if we try to plan ahead for "possible cases" before we know what they actually are, we're just making things more verbose and rigid if we were wrong).

3) When the new requirements actually come, we won't have time to rebuild everything, and thus we need to build on top of what we have, adding things that go to new directions and for which our previous structures are not ideal

Rinse and repeat.

The only way to avoid debt is to work on smaller, constrained problems, that don't change and which doesn't have to adapt to changing environments much either (e.g. write the 'grep' program). This gives us all the time to polish our implementation, rewrite everything we want, etc.