Casus Belli Engineering

Consider a South American fishing village culture, which didn't do concepts of "shit happens", nor "unintended consequences", nor "systems failure". So everything that goes wrong, is the result of some one individual's intent, exercised by direct action or by supernatural whammy. Your neighbor. Your family. Your enemy. Some fish escape the group net? Gather around to figure out who did it. Your plant not growing well? Stub your toe? Pay the witch doctor to tell you who whammied it/you, and to whammy them back. Described as a singularly toxic interpersonal environment.

Now moving subcultures to a safety/learning/challenge culture is so very hard (aviation CRM, etc), perhaps it's a valid approximation to view its absence as fixed. But having just read a comment suggesting unaddressed climate change should be blamed on the science community because reasons, I'm sensitized just now to "our local cultural dysfunction is simply human nature - it's them that's the problem". Even acknowledging bad actors fueling the dysfunction in which they thrive.

I put forward a slightly different position: Agile evolved from consulting shops, where suspicion is built in to the contract process. Both sides have an undercurrent of "are these people trying to scam us?", with regards to how much work for how much money and what results.

In that context, Agile ends up as "two week waterfall": you deliver a smaller set of things, more frequently. That compresses the blame cycle, and reduces the maximum size of disagreement.

The author has clearly witnessed politically-motivated rewrites, a real and frustrating phenomenon. But instead of scoping the problem to its actual domain (low-trust orgs, weak engineering culture, toxic leadership), he constructs a grand unified theory where all architectural replacement is suspect. Every refactor becomes a potential casus belli. Every advocate for change is a potential high priest.

Most refactoring decisions aren't triggered by a single production incident. They're driven by accumulated evidence that the current architecture no longer fits the business, or that multiple root cause analyses have independently converged on a structural problem. That's not scapegoating, that's engineering.

The Agile example makes this worse, not better. Yes, Agile was overhyped and badly implemented in many places. But using that to indict the entire movement as Girardian ritual is precisely the logical move the author claims to be critiquing: take some real failures, blame them on a paradigm rather than specific implementations, declare the whole thing rotten. He scapegoats Agile to validate his theory about scapegoating.

The pattern he describes exists. It's just not as universal as he needs it to be to make the argument work.

Maybe this should have been at the start of the blog post, and not the end. Anyway, I don't really agree with it.

Everything that works is its own form of engineering even when people don't recognize it. If your workplace is hitting optimal success despite being hostile to "real engineering", it originates in the types of problems being solved.

So then, the "real real engineering" is in reducing friction between various groups, and that often takes the form of a communication "silo". Your discomfort and confusion may actually be a significant part of the business success.

Ultimately, you choose to work there. Your happiness is not an indicator of whether the business is optimal. Your stubborn insistence on certain idealistic principles may be what Ralph Waldo Emerson referred to as "a foolish consistency". As anyone who has engineered a thing can confirm, some problems just suck and the optimal solution is full of tension.

Although I have been in the world of waterfall development back in the day and I see zero ways in which waterfall is beneficial for the vast vast majority of the projects.

(There are industries and projects where waterfall suits way better than agile up to a point where using agile would be absurd. Think NASA software and such. But people in those industries usually know really well why they use this process and have no need to engage in religious wars with outsiders.)

So while the article is excellent I do not agree that waterfall was a scapegoat and agile was Casus Beli engineering.

>The danger here is not the scapegoating itself; humans will scapegoat at all times.

Your humans are faulty, request refund.