Technical Debt Considered Harmful, Part I

Gil Zilberfeld explains how technical debt is confusing, and instead using thermodynamics to explaining the benefits of clean code and refactoring
Standard

Goodheart’s Law states that when a metric becomes a goal, it is no longer a good metric.

I don’t know when technical debt became a metric. But SonarQube calculates and reports it as such. If this calculation is correct (you must be scratching your head right now) people may assume that once they eliminate it, according to the calculation, they are debt free.

Of course, they are not. The technical debt metaphor (yes, there’s no real metric) was supposed to help explain the idea of comparing technical tasks to feature tasks, which are considered more valuable. Technical tasks, like adding tests, refactoring and simplifying the code and architecture don’t have an immediate value, compared to “real” features (I know, it’s perceived value, not necessarily an  actual one). But not doing the technical stuff makes adding feature value slow in the long run. The deeper the debt, the slower you get with the new features.

Business people, however, don’t understand how “not working on features” helps features get built. Organizations that have evolved beyond that don’t require technical debt use, since they already understand the impact.

I don’t use technical debt in my vocabulary anymore. So I needed an alternative. When I studied engineering I took a couple of courses in thermodynamics. Little did I know then, how well they relate to coding.

Ready to learn a bit?

A system has different kinds of energy in it. They can be kinetic, electrical, or potential energy which can transform into other types energy. Energy can be transformed into “work”. In physics, “work” is the implementation of potential energy. In a closed system, energy is conserved, but as we all know, no system is really closed, and therefore every system cannot conserve all its energy, unless we add more energy into it – like heat it, charge it, throw it real fast. You get the idea.

Next, there’s entropy. Entropy is basically the chaos in the system. Another way to look at entropy is from a perspective of energy. Entropy is the amount of energy that we cannot use to do work. We can’t transform it into useful kind of energy, because it gets wasted.

Now, if left unattended, given enough time, chaos takes over. In energy terms, we lose the energy, since it cannot be conserved. Entropy grows, unless we put more energy into the system.

Reminds you of something?

Part II is all about energy and entropy in code.

Leave a Reply

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