Technical Debt Considered Harmful, Part II

Technical debt and code entropy - same same, or different?
Standard

Last time, I gave you the short-short version of thermodynamics. We talked about how entropy grows rampant, as well as creating waste in the system, if it doesn’t have constant energy input.

Let’s get back to technical debt. The technical debt metaphor has two parts: First, it slows us down in the long term. The second part is that it can go away – for a price.

You can already see the resemblance to our energetic system. The code has growing entropy. Chaos, or our inability to control the code, keeps growing. The chaos creates energy-wasting traps, and we deliver slower.

What are these traps?

If we don’t have tests, we tend not to refactor. If the code is not readable, we’re very cautious about adding new functionality. If the code is one giant method, we tend to add parts of the new functionality within the giant method, otherwise we risk breaking stuff. These are the time-sucking traps we need to avoid, instead of going forward fast.

So the code grows, laying more energy traps for us, which slow us even further the next time we go into the swamp.

We need to invest energy in the system to remove the traps. We need to take care of the code – spend time in refactoring, improving it, so the next time the swamp is easier to navigate through. In the long run we sustain velocity, instead of losing energy. The swamp gets clearer, but never gets clear.

The second part of the metaphor is where I think it fails – since it’s not really a loan, we’re never going to fully repay it. There’s not going to be an endpoint where it is repaid. There’s not going to be a single point of repayment. There’s always something more important to do. And since we never stop and “repay it” – we’re stuck in a downward spiral.

In the real world, the best we can do is keep things under control the best we can. We do that with clean code, refactoring, adding tests and code reviews and design reviews. Those reduce the energy traps, and maintain sanity. Entropy does *not* grow unchecked. But since entropy wants to grow, we will keep doing the work, putting energy in, but there is no end in sight. Or at all.

In some situations we believe we can repay the loan fully. We later discover we got to a “good enough” point. If we continue after that, the way we worked before, we see that the “good enough” point is not only good enough, it was just a temporary mirage.

I’ve stopped using technical debt as a metaphor, because it doesn’t correspond with reality. In real life, the business people have no problem sacrificing long term costs for short term gain. The loan can never be repaid.

Instead we should continuously lower the code entropy, get rid of the black holes, and putting energy, into clearing the code swamp.

2 thoughts on “Technical Debt Considered Harmful, Part II

  1. Christopher

    ‘I’ve stopped using technical debt as a metaphor, because it doesn’t correspond with reality. In real life, the business people have no problem sacrificing long term costs for short term gain. The loan can never be repaid.’. – how does the thermodynamics metaphore solve this? Is it more comprehensible for business people? Ward Cunningham used finance world analogy to reach minds of people who handled money. Many POs or PMs as we call them don’t talk money anymore, maybe that’s the real problem?

    • Gil Zilberfeld

      Thanks Christopher,

      It’s like all business people have gained knowledge in physics, right?
      No, but they (at least the ones I have talked to) get entropy. Refrigeration too, by the way.
      You do raise an interesting point though – maybe PMs don’t understand how finance works anymore. That’s a generalization, of course, but I do meet a lot of POs who are distanced from the business, they just get orders from PMs about priorities.
      In any event, the system is designed to measure the people in it in the short term. People are incentivized to not invest in the long term, and any investment in that gets downgraded almost automatically.

Leave a Reply

Your email address will not be published. Required fields are marked *