Skip to content
Tech News
← Back to articles

Casus Belli Engineering

read original more articles
Why This Matters

This article highlights the importance of understanding systemic failures and their social implications within the tech industry. It emphasizes how organizations often resort to scapegoating and ritualistic fixes, which can hinder genuine problem-solving and erode trust. Recognizing these patterns is crucial for fostering more resilient and transparent technical practices that prioritize root causes over superficial fixes.

Key Takeaways

Few things in a professional environment are more important than a lasting impression; be it for building trust or conveying unappreciated quality, it is often what kills any system: people lose confidence in it. Imagine seeing something always faulty; a stakeholder sees a failed commitment. They do not see, and cannot see, the distinction between the feature that failed and the foundation it rests upon. To them, the system is monolithic; if any part fails, the whole is suspect. This perception, though technically naive, creates social stress that technical accuracy cannot dispel.

As failures accumulate, pressure builds; someone must be responsible, and something must be done. The organization demands resolution, not in the form of root cause analysis or targeted fixes, but in the form of visible action, decisive change and ritual purification. The tension must be released.

What follows is as old as human society itself: the stressed group selects a victim, to which the guilt is assigned, and finally, the victim is destroyed. Through its destruction, social cohesion is restored. The Aztecs sacrificed captives atop pyramids to ensure the sun would rise. We sacrifice codebases in conference rooms to ensure projects will ship. The mechanism is identical; only the altar has changed.

René Girard observed that human communities in crisis often resolve internal conflict through scapegoating: the selection of a victim to bear collective guilt, whose expulsion restores order. The scapegoat need not be guilty; it need only be acceptable as a target. Its guilt is constructed through narrative, not discovered through investigation (see [5], [6]).

Some dangerous individuals, however, institutionalize such ritualistic practices into what I call Casus Belli Engineering: the use of perceived failure as pretext to replace working systems with one's preferred worldview. The broken feature is the crisis that demands resolution. The foundation becomes the scapegoat, selected not for its vulnerability and the convenience of its replacement. And in most cases, this unfolds organically, driven by genuine belief in the narrative. These individuals are truly alchemists at heart; they have the power to manipulate the phantoms of lasting impressions to their favor [14]. They do not wait for crisis, they nourish it. They do not stumble into scapegoating, they engineer it. They fabricate casus belli deliberately, using the ancient machinery of collective violence to remake systems in their own image. These are not confused engineers making honest mistakes in attribution. These are political operators who have discovered that technical failure can be converted into organizational power.

The danger here is not the scapegoating itself; humans will scapegoat at all times. The danger is those who have learned to trigger the mechanism strategically, who can reliably convert any failure into an opportunity to destroy what exists and build what they prefer. They are the high priests of a secular religion, and their rituals shape our technological landscape more than any technical merit.

The Scapegoat Mechanism

In software organizations the pattern obeys the same liturgy. What follows is my perception of its unfolding.

When failures generate tension, demand explanation, and threaten careers, the organization selects a scapegoat rather than confront the actual causes, which might implicate recent decisions, current leadership, or systemic dysfunction. It must be plausibly proximate to the failure (a dependency, a framework, an architectural pattern), unable to defend itself (because it is old, unfashionable, or championed by people who have departed), and replaceable with something the accusers prefer. This last criterion is the essential one: the scapegoat's destruction must clear the ground for the accuser's alternative.

Once selected, the scapegoat is ritually condemned. Its guilt is established through repetition ("We keep having problems because of X") while the actual causes (error handling, testing, operational neglect) recede into the background. X becomes the problem, and X must be destroyed. The war's stated objective has nothing to do with its actual aim: replacing one paradigm with another, under the cover of failure.

... continue reading