In Defense of the Shifting Foundation

There’s a mantra in our line of work, repeated with the solemnity of a sacred vow: make your foundations immutable. Build once, deploy forever. Your base image, your core configuration—these should be artefacts, frozen in time and tested to perfection. The goal is a state of perfect consistency, a known quantity from which all else flows. It’s a comforting ideal, this digital terra firma. But I’ve come to believe it’s a subtle trap. What if, instead of building on granite, we’re secretly paving over quicksand?

The argument for immutability is, on its face, unassailable. Consistency reduces cognitive load. It minimises the dreaded “it worked on my machine” syndrome. By locking down the foundation, we supposedly eliminate a whole class of unpredictable failures. Yet, this very act of locking down introduces a more insidious fragility. A system whose base hasn’t been touched in three years isn’t a monument to stability; it’s a sleeping giant of technical debt. The world outside does not stand still. Libraries are patched for critical security flaws, new kernel-level vulnerabilities are discovered, and hardware evolves. Our perfect, immutable foundation slowly becomes a museum piece, increasingly alienated from the ecosystem it inhabits.

I propose a counterintuitive practice: the deliberately shifting foundation. This isn’t about chaotic, untracked changes. It’s about building a culture and tooling for continuous, gentle, and intentional movement at the base layer. Instead of fearing an update to a base Docker image or an OS package, we should schedule it, automate it, and welcome it as a routine form of hygiene. The goal is not to achieve a permanent state, but to master the process of state transition.

Think of it like maintaining a footpath through a forest. The immutable approach would be to pour a permanent concrete slab. It’s solid, yes, but over time, tree roots will heave it, and the forest will grow around it, making it obsolete. The shifting foundation approach is to maintain a gravel path. It requires more frequent attention—raking the gravel, clearing debris—but it remains in harmony with the living ecosystem. It adapts. When a small change is a weekly occurrence, it’s a minor event. When change is deferred for years, it becomes a terrifying, all-hands-on-deck migration.

The Virtue of Constant, Gentle Nudges

By forcing small, regular foundational updates, we keep our systems limber. Our automation for applying changes stays sharp because it’s used constantly, not just in panicked emergency patches. More importantly, our understanding of the system’s dependencies remains current. We encounter and solve integration problems when they are small and manageable, not when they have compounded into a crisis.

This philosophy embraces the reality that software is not a static construct but a living one. Reliability, then, isn’t born from perfect stasis, but from a proven, resilient capacity to change. It’s the difference between the strength of a rock and the strength of a willow tree in a storm. The rock may seem stronger, but the willow bends and survives. Our systems should be willows. They must be able to sway with the winds of necessity, their roots—our processes—strong enough to hold fast while their upper layers adapt. The most reliable foundation isn’t the one that never moves; it’s the one you know, with certainty, can be moved safely at any time.

Notes & further reading

A few pages I came back to while writing this: