19 Mar 2026 3 min read antifragility

🔧 IT Keeps Reinventing Itself. Industry Keeps Getting It Right.

Each wave brings language, structure, and renewed enthusiasm. Yet, despite this constant motion, the same problems return with remarkable consistency: slow delivery, unclear ownership, fragile systems, and persistent rework.

The Illusion of Reinvention

IT continuously reinvents itself, often with a sense of urgency that suggests something fundamentally new is about to emerge. New frameworks appear, new roles emerge, and new models take centre stage, each carrying the promise of a reset.

Agile. DevOps. Platform. AI-first.

Adoption rarely fails. Understanding does.

Agile turns into theatre. DevOps becomes a label. Platform evolves into another dependency. The organisation speaks the language fluently, yet the system itself does not behave any differently. Form receives attention. Substance does not.

Borrowed Ideas, Shallow Roots

Much of what IT presents as innovation is not new. It is borrowed, often from industries that solved these problems decades ago under far stricter constraints.

Flow originates in manufacturing. Feedback loops belong to control systems. Autonomy reflects military doctrine. These ideas have depth, history, and proven application.

Those industries did not stop at naming concepts. They built systems that enforced them, embedding principles into structure, process, and behaviour.

In IT, vocabulary takes precedence. Concepts receive new names, new packaging, and rapid rollout. The surface changes quickly, yet the underlying system remains largely untouched.

Concrete Signals of Misunderstanding

The gap between intent and reality becomes visible in everyday situations.

Agile, in theory, promotes adaptability and fast feedback. In practice, it often produces fixed scopes hidden behind flexible language, ceremonies that lack real decision-making power, and teams measured on output rather than outcome.

DevOps aims to remove friction between development and operations. In practice, it frequently results in a renamed team acting as a gatekeeper, pipelines that automate inefficiency, and ownership fragmented across too many actors.

Platform thinking should create leverage and autonomy. In practice, it often delivers central teams overloaded with requests, internal products that require constant support, and increased dependency rather than independence.

These are not failures of the concepts themselves. They are failures of understanding and, more importantly, failures of implementation.

What Industry Gets Right

Other industries operate under constraint, and constraint enforces clarity.

In mechanical engineering, tolerances define success, misalignment disrupts the entire system, and failure carries immediate consequences. There is little room for approximation or ambiguity.

In automotive engineering, systems integrate rather than accumulate. Reliability is tested under stress, and iteration happens within clearly defined boundaries.

In domains where failure is not acceptable, simplicity is engineered deliberately, ambiguity is removed early, and responsibility remains explicit.

There is no theatre, no ambiguity, and no illusion of progress. There are only systems that function as intended because they have been designed to do so.

A critical element often overlooked is the immediacy of feedback. In these industries, outcomes connect directly to reality. A component fits or it does not. A system holds or it fails. The loop between action and consequence remains short, visible, and undeniable.

This outcome-driven connection to reality enforces discipline. It removes interpretation, limits abstraction, and anchors decisions in facts rather than perception.

For IT, this represents a missed entry point. Rebuilding a solid grounding does not begin with new frameworks. It begins by restoring tight feedback loops where outcomes reflect reality quickly enough to guide behaviour and design.

The Comfort of Abstraction

IT follows a different path, largely because failure carries limited immediate cost and consequences often arrive later.

Optimisation shifts towards speed over stability, visibility over outcome, and coordination over ownership. Deferred work becomes acceptable. Fix later. Rewrite later. Scale later.

This approach creates the appearance of efficiency and progress. In reality, abstraction conceals structural issues. It hides misalignment, fragility, and weak design decisions until exposure becomes unavoidable.

A system can appear healthy for a long time while quietly drifting away from coherence.

The Theatre Problem

At this stage, performance begins to replace engineering.

Ceremonies take place, boards update continuously, and pipelines execute as expected. Everything appears correct from the outside.

Yet improvement does not follow.

The underlying system lacks deliberate design. It has been assembled incrementally, shaped by local decisions rather than systemic thinking.

No ceremony corrects structural flaws. Execution continues, yet direction weakens, and over time, the gap between activity and outcome widens.

What We Still Have to Learn

The fundamentals are not absent. They are neglected.

Craftsmanship requires discipline sustained over time. Systems require deliberate design, not accumulation. Simplicity emerges from constraint, not convenience.

These principles are not new. They underpin industries that build systems intended to last, systems that must operate reliably under real-world conditions.

IT does not lack intelligence. It lacks respect for these principles.

Relearning them does not require invention. It requires attention, discipline, and a willingness to operate within constraints rather than avoid them.

In Conclusion

The issue does not lie in the pace of evolution. It lies in the loss of continuity.

Every few years, the cycle resets. New language appears, new models emerge, and familiar problems return under different names.

Progress resumes when IT reconnects with what other industries never abandoned: systems thinking, constraints, craftsmanship, and the discipline required to build systems that do not require reinvention every two years.

(References and deeper exploration in the comments.)