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.
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.
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.
> 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.
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.
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
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.
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.
Just want to say I really like the style for this page, simple and understated but attractive.
This misses the worse scapegoating kind in software organizations, the kind which end with an actual engineer being sacrificed
> 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.
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.
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...