The irony is that this post is itself a textbook example of the scapegoat mechanism it describes.
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.
> 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
I don't think the author did that at all. He was fair to interactive development. He specifically points out the scapegoating of waterfall, where the methodology was misrepresented in order to create the space for agile.
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.