Always Be Refactoring

We have a tendency to treat things that have already come to pass as if they’re permanent features of the universe. Taking them for granted, like we do with mountains, electricity, and the postal service. We all know that everything break down over time. Yet we don’t generally act to prevent it until we’re directly impacted or impeded. We can’t help but to ignore maintaining the most basic things we rely on. But mountains move, electricity flickers, and sometimes mail doesn’t show up.

This is closely related to the mechanics of technical debt:

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on.

But the mechanism seems more general… and inevitable. There’s always debt. Even thoroughly thought out plans meticulously executed, thoughtful of corner cases, eventually drag us down and blow up. As time goes on things change, assumptions that held cease to hold, and the magnitude of risk becomes volatile.

Every decision to build, do, or be something involves a tradeoff — not just at the time of the decision but ongoing over time and over multiple dimensions:

• There are things you cannot build on top of what you’ve already built. Being a neurosurgeon does not lend itself to a future career as a trapeze artist. Decisions you make today have tradeoffs tomorrow.
• Context and facts change over time. Concrete erodes and breaks down under pressure, bridges collapse. Today’s tradeoffs become different tradeoffs tomorrow.

These mechanisms are general and show up everywhere: psychological debt, business model debt, org structure debt, cultural debt, regulatory debt, etc. All our past decisions haunt us.

The only method I’ve found for dealing with this is to commit to refactoring as a way of life. Which implies constant reassessment against the environment to determine the nature and extent of refactoring required, the risks posed by doing more or less, sooner or later. And supports the general notion of holding strong opinions weekly.

Strong opinions held weakly as a principle implies a commitment to disproof of theory and anti-dogmatism. Which requires not investing our personal identities, not seeing ourselves made up of, whatever things we might have built or believed in the past.

This is how we arrive at one of the operating principles in this discussion of applying theoretical tools like OODA, Mapping, and Antifragility to practice: always be refactoring.

Going down the rabbit hole of collapse
The collapse of complex systems comes from somewhere. Problems have to encounter fissures that concentrate and magnify their impact, giving small or unexpected events huge leverage (Black Swans).

In natural systems, this is both a given and generally useful to the protection of the overall system over time. Periodic collapse at all layers is required for evolutionary progress for living systems and for greater stability (finding newer/better local/global valleys over some time period).

In human systems, the fissures need to be constantly found and repaired or manipulated to reduce their blast radius (failure domain) — which changes over time. Thus increasing our ability to deal with them through constant testing/failure/repair (antifragility).

But undergoing this constant cycle requires not being attached to any particular abstraction or model of how the world works. Because every model hides discontinuities at the lower level and glosses over handoffs, gaps, and fissures between objects at the more granular scale (because they appear continuous at the scale of the model).

It requires being willing to abandon the abstraction when reality proves it no longer applies, has become wrong, is broken, etc. And it requires constant checking of any model at any scale against the things over which it is abstracting at the lower scale for fissures (risks) that need refactoring.