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.

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.

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.

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.

Just want to say I really like the style for this page, simple and understated but attractive.

undefined

undefined

This misses the worse scapegoating kind in software organizations, the kind which end with an actual engineer being sacrificed

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.

> 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.

[dead]

[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.