[HN Gopher] Casus Belli Engineering
___________________________________________________________________
Casus Belli Engineering
Author : b-man
Score : 65 points
Date : 2026-04-18 01:14 UTC (21 hours ago)
(HTM) web link (marcosmagueta.com)
(TXT) w3m dump (marcosmagueta.com)
| sublinear wrote:
| > 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.
| midtake wrote:
| 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.
| mncharity wrote:
| One sidebar caveat re "Rene 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.
| aquariusDue wrote:
| If someone wants to dig deeper into the scapegoat
| principle/process I recommend picking up Rene 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.
| BobbyTables2 wrote:
| Kinda like how when a product isn't selling well, fire the
| engineers!
|
| No need to blame the sales or management...
| midtake wrote:
| 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.
| cgio wrote:
| 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.
| balamatom wrote:
| 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...
| breppp wrote:
| This misses the worse scapegoating kind in software
| organizations, the kind which end with an actual engineer being
| sacrificed
| veltas wrote:
| Just want to say I really like the style for this page, simple
| and understated but attractive.
| egorfine wrote:
| 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.
| yellow_lead wrote:
| 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.
| quuxplusone wrote:
| "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.
| pjc50 wrote:
| 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.
| arter45 wrote:
| Interesting perspective
| balamatom wrote:
| 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.
___________________________________________________________________
(page generated 2026-04-18 23:01 UTC)