One sidebar caveat re "René Girard observed that human communities in crisis often resolve internal conflict through scapegoating", and "humans will scapegoat at all times", and treating this as "human liturgy", rather than as culture-specific pathology.
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.
If someone wants to dig deeper into the scapegoat principle/process I recommend picking up René Girard's I See Satan Fall Like Lightning, I stopped halfway though it a few years ago and intend to resume it sometime. Also I expected to see the book itself as reference in the blog post and was surprised when I checked the references section.
Scapegoating is a very real problem of dysfunctional cultures, but I think the author undermines their point at the end by citing someone who thinks that lisp is the solution.
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 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.
> It is politics costumed as engineering, ritual costumed as analysis, scapegoating costumed as problem-solving. Engineering is the commitment to understanding what actually causes what, to targeted remediation grounded in evidence, to the disciplined separation of correlation from causation, especially when the narrative is seductive.
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.
I would argue the author even deliberately misunderstands engineering.
> Engineering is the commitment to understanding what actually causes what [...]
This sounds like science to me. Engineering is the exploitation of scientific principles for human reasons. Whether those reasons are "clean water" or "war" does not take away from the essence of their engineeringness.
I would call it Scapegoat Engineering, but yes, it is a phenomenon that I've seen. However, people are not as susceptible to it as you may think. I see it happen more when the group doesn't understand the scapegoat well. For instance, a language, framework, API, etc is painted as the scapegoat. Then, it's harder to refute, when in reality the group was holding/using it wrongly due to lack of experience.
"Scapegoat-Driven Development" is right there! It would have fit OP's message better, too, in that the thing he's complaining about is maybe not worthy of the name "engineering" but is unquestionably some kind of "development."
But "waterfall" and "Agile" are such soft targets. I'd rather have seen a blog post with real war stories about real components/idioms/files/libraries from real codebases, not just another "methodologies" piece.
And is there an inverse problem, "scapegoat-driven stagnation," where we can't even think about addressing X,Y,Z until we have gotten rid of G (or finish the long-planned but as-yet-unstarted migration off of G)? That is, where G itself doesn't actually block these projects, but everyone uses G as a convenient excuse to postpone them anyway.
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.
This is probably not top-level worthy and I'm going to hell for this but this reads like slop. Maybe I have trust issues with content now, because everything looks like slop. But I am pretty sure I can get that essay out of claude and just sed the funny grammatical characters out.
I didn’t get the slop feeling. I could see some long winded argumentation that diminished the messaging. The important aspect in this is that someone with political inclination can use the powerful imagery of a scapegoat sacrifice to appeal to the psychological bias that we are better than previous people and fight a casus belli with another one.
One sidebar caveat re "René Girard observed that human communities in crisis often resolve internal conflict through scapegoating", and "humans will scapegoat at all times", and treating this as "human liturgy", rather than as culture-specific pathology.
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.
If someone wants to dig deeper into the scapegoat principle/process I recommend picking up René Girard's I See Satan Fall Like Lightning, I stopped halfway though it a few years ago and intend to resume it sometime. Also I expected to see the book itself as reference in the blog post and was surprised when I checked the references section.
Kinda like how when a product isn’t selling well, fire the engineers!
No need to blame the sales or management…
Scapegoating is a very real problem of dysfunctional cultures, but I think the author undermines their point at the end by citing someone who thinks that lisp is the solution.
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.
Interesting perspective
This misses the worse scapegoating kind in software organizations, the kind which end with an actual engineer being sacrificed
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.
> It is politics costumed as engineering, ritual costumed as analysis, scapegoating costumed as problem-solving. Engineering is the commitment to understanding what actually causes what, to targeted remediation grounded in evidence, to the disciplined separation of correlation from causation, especially when the narrative is seductive.
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.
I would argue the author even deliberately misunderstands engineering.
> Engineering is the commitment to understanding what actually causes what [...]
This sounds like science to me. Engineering is the exploitation of scientific principles for human reasons. Whether those reasons are "clean water" or "war" does not take away from the essence of their engineeringness.
I would call it Scapegoat Engineering, but yes, it is a phenomenon that I've seen. However, people are not as susceptible to it as you may think. I see it happen more when the group doesn't understand the scapegoat well. For instance, a language, framework, API, etc is painted as the scapegoat. Then, it's harder to refute, when in reality the group was holding/using it wrongly due to lack of experience.
"Scapegoat-Driven Development" is right there! It would have fit OP's message better, too, in that the thing he's complaining about is maybe not worthy of the name "engineering" but is unquestionably some kind of "development."
But "waterfall" and "Agile" are such soft targets. I'd rather have seen a blog post with real war stories about real components/idioms/files/libraries from real codebases, not just another "methodologies" piece.
And is there an inverse problem, "scapegoat-driven stagnation," where we can't even think about addressing X,Y,Z until we have gotten rid of G (or finish the long-planned but as-yet-unstarted migration off of G)? That is, where G itself doesn't actually block these projects, but everyone uses G as a convenient excuse to postpone them anyway.
Just want to say I really like the style for this page, simple and understated but attractive.
Excellent article.
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.
Idk if written by slop or just machine-translated into slop from a language that is not as sloppy as English, but enabler mentality nonetheless:
>The danger here is not the scapegoating itself; humans will scapegoat at all times.
Your humans are faulty, request refund.
[dead]
This is probably not top-level worthy and I'm going to hell for this but this reads like slop. Maybe I have trust issues with content now, because everything looks like slop. But I am pretty sure I can get that essay out of claude and just sed the funny grammatical characters out.
I didn’t get the slop feeling. I could see some long winded argumentation that diminished the messaging. The important aspect in this is that someone with political inclination can use the powerful imagery of a scapegoat sacrifice to appeal to the psychological bias that we are better than previous people and fight a casus belli with another one.
Maybe more like translated by slopmachine.
The argument TFA makes is rather facile nonetheless.
Like this stuff is intuitively known to any Ukrainian 3rd grader but not to Western business leaders?
No wonder yall got an AI problem...