[HN Gopher] Simple sabotage for software (2023)
___________________________________________________________________
Simple sabotage for software (2023)
Author : adammiribyan
Score : 206 points
Date : 2024-06-16 09:39 UTC (13 hours ago)
(HTM) web link (erikbern.com)
(TXT) w3m dump (erikbern.com)
| ohyes wrote:
| This is interesting because a lot of the decisions to "sabotage"
| are about convincing people to attempt to cover their own asses.
|
| I think in that light, number 1 is to foster an atmosphere of
| fear where anyone attempting to make things better will be
| confronted if things don't go perfectly.
| misswaterfairy wrote:
| I've noticed a lot of consultants I've worked with over the years
| do most, if not all, of these things.
| quantum_state wrote:
| Very humorous ... ironically, it's happening in many companies...
| roenxi wrote:
| The major thing that springs to mind here is I've never seen a
| compelling reason to believe that the original CIA suggestions
| actually worked. In my experience workers like that exist
| naturally and organisations are great at just sidelining them. I
| think in that section the CIA was just writing a listicle that
| sounded good [0].
|
| The way to cripple a company is to get bad people promoted into
| management and have them optimise something plausible but not
| profitable. Like what happened in a lot of slow-fail engineering
| companies - insist on maximising the profit metric to the point
| where the actual product becomes compromised. That strategy can
| be intiated from almost anywhere in management too because a
| constant "what if we optimise for profit" [1] usually does well
| at meetings.
|
| Being a destructive CTO is almost too easy. Just don't do
| anything much, weed out any competent people in the level below
| you and develop a culture of pushing blame aaaaalllllllll the way
| down the org chart, ideally out of the technical part of the
| tree, so that nothing broken gets fixed. When people catch on,
| allow blame to move 1 level up the org chart and do a big shakeup
| to clear out any institutional knowledge that might have built up
| in spite of you. That game can go on for years.
|
| [0] I've seen people where "do things through official channels"
| and "demand written orders" would have made them more productive.
| We are our own worst enemies.
|
| [1] Yes, the irony here is that naive optimising for profit is
| typically not profitable.
| hobs wrote:
| Oh yeah, this one really is fun. We used to joke that the CTO
| of one of the companies I worked for made a killing as his
| second job was for our competitors.
|
| Turns out the dude has been doing that for about 15 years
| between various places and now is about to retire, blameless in
| the eyes of everyone who doesn't understand what happened.
| andrei_says_ wrote:
| Doing what? Getting paid by a competitor to destroy his
| current company?
| hobs wrote:
| No, being incompetent to the point where if you squinted he
| might as well be.
| jt2190 wrote:
| Refer to the section "(11)(b) Managers and Supervisors"
| https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...
| krisoft wrote:
| > I've never seen a compelling reason to believe that the
| original CIA suggestions actually worked.
|
| Let's set asside the fact that the document wasn't written by
| the CIA.
|
| The purported goal of this document was to provide practicaly
| applicable advice to the regular citizen who found themselves
| under enemy occupation. Most concretely to be given to the
| French people who did not like the German occupation.
|
| You are talking about the strategy "working" or "not working"
| as if these are binary things. The goal here was not that these
| simple steps will bring Germany to their knees but to increase
| the cost of the occupation. To cause enough deniable friction
| which bogs down the resources and make everything just a bit
| more inefficient.
|
| > In my experience workers like that exist naturally
|
| They do. And that is the point. That is what makes these
| strategies deniable.
|
| > and organisations are great at just sidelining them
|
| If that is your experience I would love to work where you
| worked. In my experience when someone is following this
| strategy sidelining only happens slowly and at great costs. One
| of the many costs is people comitting avoidable blunders when
| they dismiss real and well reasoned objections in their haste
| to cut through a sea of useless ones.
|
| > to get bad people promoted into management
|
| Sure. But that takes time. You are thinking on a different time
| scale than the authors of this document were thinking about.
| The document was published in Jan 1944. The Normandy landings
| happened in June the same year and by the end of the next year
| the war was won. You don't have time to slowly promote bad
| people into management. If a dude who read your booklet bumbles
| about a bit and delays the repair of a train line by days that
| is a win in this context. Nobody expected that Germany is going
| to collapse on their own just because enough people sabotage
| meetings and plug up toilets. (That is by the way also a
| suggestion from the manual 5.1.b.2. Somewhat less often cited
| than the points applicable to office work.)
| fuzzfactor wrote:
| >>workers like that exist naturally
|
| Ones whose only significant effort (if any) is to be a
| mainstream employee in all other ways since _nothing_ will
| ever make them productive or capable of efficient operation.
|
| >> and organisations are great at just sidelining them
|
| >If that is your experience I would love to work where you
| worked.
|
| Me too. That does seem like uncommon good fortune. Too often
| these are the ones that get promoted into higher levels of
| mangement, it is so widespread among different companies it
| goes undetected in the way the CIA intended. Plausibility
| beats productivity.
| _djo_ wrote:
| > Let's set asside the fact that the document wasn't written
| by the CIA.
|
| What do you mean? The CIA has publicly stated that the
| document was written by the OSS, its wartime predecessor. [0]
|
| [0] https://www.cia.gov/stories/story/the-art-of-simple-
| sabotage...
| oldgradstudent wrote:
| You can do far far worse than naive optimizing for profit.
| Optimizing for *REPORTED* profit.
|
| People learn very quickly to manipulate the reporting,
| modeling, and accounting.
|
| Just less than two decades ago we had the entire financial
| system lending massive amounts of money to the worst possible
| borrowers and REPORTING massive profits.
| mattacular wrote:
| > [1] Yes, the irony here is that naive optimising for profit
| is typically not profitable.
|
| Yes but only over a relatively long time period, which the
| overarching system itself is not incentivizing anyone to look
| at too carefully.
| stavros wrote:
| They do work, we had a director who did all that in a previous
| company (probably unintentionally), and things ground to a halt
| and productivity fell to zero.
| thih9 wrote:
| > naive optimising for profit is typically not profitable
|
| Naive optimizing for anything, while consuming that metric as
| fuel, has that effect.
|
| A.k.a. "We will continue having meetings until we figure out
| why productivity is dropping".
| chrisandchris wrote:
| Duplicate (15d) https://news.ycombinator.com/item?id=40538920 and
| (5m) https://news.ycombinator.com/item?id=38707591
| behnamoh wrote:
| @dang
|
| maybe merge the threads?
| jwilk wrote:
| There are no comments in either of them.
| krisoft wrote:
| > CIA produced a fantastic book during the peak of World War 2
| called Simple Sabotage.
|
| Not quite right. The Office of Strategic Services did that. The
| CIA was created only in 1947 several years after the end of the
| second World War in 1945.
| hinkley wrote:
| The head of the OSS also founded the CIA, so is it really that
| big of a stretch?
| llm_trw wrote:
| > 4. Bring up irrelevant issues as frequently as possible.
|
| Excellent. Continue the good work.
| 01HNNWZ0MV43FF wrote:
| Let's keep talking about this. How is two years "several"?
| That's "a couple" literally and maybe "a few"
| 082349872349872 wrote:
| So while we're here: anyone know if Sonia Brownell ever
| worked with PWE before working with IRD? (or have suggestions
| as to where to look for this sort of thing?)
| throwawayqqq11 wrote:
| Sorry, but i have to flag your comment.
|
| 1) dang has to decide whether this is too snarky or not.
|
| 2) Please stay on topic, its about CIA or not.
|
| 3) Its hardly " _frequently_ bringing up irrelevant issues ".
|
| Have i missed something?
| oopsallmagic wrote:
| A sense of humor?
| llm_trw wrote:
| I'm pretty sure the post you're replying to is a joke.
|
| We need to form a sub comittie to figure out if it is.
| jwilk wrote:
| You missed
| https://news.ycombinator.com/newsguidelines.html:
|
| > _If you flag, please don 't also comment that you did._
| c0balt wrote:
| Flagging should be accompanied by a reply to the original
| post. Otherwise this bypasses the official channel and
| the op won't be able to receive proper feedback. Such
| issues should also be referred to the moderation
| committee and the awareness team. /s
| desio wrote:
| Clever framing of the authors own biases. I'd argue that for at
| least some of these, the opposite behaviour would be the true
| sabotage.
| ohyes wrote:
| Let's make a committee to discuss! we need all the key players
| involved, so let's invite all of dev and QA, ~60 people for an
| hour long discussion?
| oopsallmagic wrote:
| What? You think the meeting was unnecessary? Well, you're the
| only one who disagrees with the outcome. Sounds like you're
| not being a team player. Let's have a meeting with HR
| tomorrow.
| mike_hock wrote:
| In fact, a sabotage manual should include the opposite action
| for each point. These are not the methods of sabotage, they're
| the methods of shrouding your sabotage in plausibility. It
| wouldn't provide you plausible deniability if doing the things
| on the list was never reasonable.
| penguin_booze wrote:
| The 'Hiring' section needs an update: ask Leetcode hard-level
| problems, and demand to witness enlightenment and an optimized
| solution in under 30 minutes. Uncertainty and doubt shall not be
| tolerated.
| davidgerard wrote:
| Mandatory RTO, tech teams first.
| julik wrote:
| About 60% of that list checks out for a place I worked at.
| eganist wrote:
| It's cute, but in quite a few industries, a lot of these are
| driven by outside e.g regulatory forces that have proven to be
| necessary ("written in blood" etc), so the better question to ask
| is how many of these process encumberments can be streamlined e.g
| with paved road approaches.
|
| Security and compliance benefit heavily from this approach, and
| I'm sure it can be extended elsewhere as well (architecture
| reviews etc).
| KronisLV wrote:
| > Make sure production environment differs from developer
| environments in as many ways as possible.
|
| I feel like this, in some capacity, is borderline inevitable in
| the modern architectures with a bunch of external services, or at
| the very least will 100% require that your devs are connected to
| the Internet all the time to be able to do anything, vs systems
| that are 100% self hostable.
|
| Or even just running a complex Kubernetes cluster with a service
| mesh and other solutions on the test/staging/prod infra vs
| loosely mapping to more lightweight options locally, unless you
| have a super beefy setup. And even then, if everything is split
| into multiple separate services far enough, you just won't be
| able to run everything locally, meaning that you need to use some
| of the components from shared dev environments which will
| inevitably lead to stepping on each other's heels.
|
| Once you go past something like Docker Compose for local
| environments, things can go sour.
| teddyh wrote:
| Im some ways, this is an unsolvable problem, due to entropy.
| You can't even step into the same river twice.
| hinkley wrote:
| I used nginx as a forward proxy a couple times before Docker
| was a thing. Poor man's service mesh still has some utility.
| xjay wrote:
| In a web context, I was thinking this when I checked out the web
| site of the Electronic Frontier Foundation (EFF) [1]; why would
| they use a thin, small typeface with light gray color on a
| bright/white background which makes the text less appealing to
| read? It must be subtle sabotage from within!
|
| (Some may counter this with Hanlon's razor [2]; Never attribute
| to malice that which is adequately explained by stupidity.)
|
| [1] https://www.eff.org/
|
| [2] https://en.wikipedia.org/wiki/Hanlon's_razor
| wgx wrote:
| I find the EFF site perfectly readable. Not sure what you're
| experiencing but it looks fine to me.
| pcloadletter_ wrote:
| I left Microsoft a year ago because the group I worked for
| checked pretty much every one of the items on this list. It was
| wildly unproductive.
| photonthug wrote:
| All this is so normalized these days that many of the items on
| this list are referred to with reverence as best practice.
|
| Plus calling these things "sabotage" isn't right even as a
| metaphor, and IMO confuses the issue. These people aren't on a
| third-party payroll, they are just self-serving.
|
| No one is creeping into your office in the middle of the night.
| You invited them over, let them in, watched them piss in the fish
| tank, and then gave them a promotion and a raise. Now you're
| surprised everyone is lining up to fuck up the place? As usual
| the value judgements are just a distraction in matters of
| economics, look at the incentives.
| oopsallmagic wrote:
| "Never attribute to malice that which can be adequately
| explained by stupidity."
| doytch wrote:
| > Build complex "self-service" systems for stakeholders in other
| teams.
|
| Is the sabotaging bit here the "complex" part?
| kstrauser wrote:
| Photo caption:
|
| > This is from the 1994 music video Sabotage by Beastie Boys. The
| lyrics are mostly about technology leadership and developer
| productivity.
|
| That caught me off guard. Well done.
| lelanthran wrote:
| Some of these conflict:
|
| > Encourage a complex dev setup: running a service mesh with a
| dozen services at a minimum.
|
| ...
|
| > Build in-house versions of almost anything that's not a core
| competency.
|
| So if you need functionality A, B, C ... H, what do you do? Do
| you build them all in-house or do you have 9 different services
| each providing the functionality required?
| isidor3 wrote:
| You build 9 different services in-house, obviously.
| dundermuffin wrote:
| You don't need that functionality, you need Ruby on Rails and a
| cold shower.
| patrakov wrote:
| The manual misses the most important step: getting rid of people
| who have even the slightest idea of how the product as a whole
| should work and/or a coherent vision of a better future. The word
| "vision" is not even present in the text. Visioners are the ones
| who can sabotage the saboteurs.
| btbuildem wrote:
| The eight rules laid out in the beginning of the article are
| strictly followed, almost word-for-word, at my workplace. Not
| ironically, not for sabotage reasons, but legitimately as "best
| practices".
|
| It's a miracle that somehow the company remains in business.
| red_admiral wrote:
| So cloud-based microservices for everything, then?
| coopykins wrote:
| That list of sabotaged software development reminds me of my time
| at Oracle
| thenthenthen wrote:
| I recall the original OSS included some more hands-on techniques,
| like throwing your files (the ones you grind with) into the
| drawer instead of laying them down carefully. I wonder what the
| equivalent in software dev. would be. Throw files into folders
| with a lot of force? Ddos? The legitimacy of this document has
| been questioned, but it is surely food for thought. And don't
| call me Cherly
| thenthenthen wrote:
| (A pegboard or tool block could have easily mitigated any wrong
| handling of the tools?)
| oopsallmagic wrote:
| The overarching point is "don't take care of your tools". So
| downloading 500 MB of dependencies and then letting them rot is
| a great example.
| namegenbyai wrote:
| a
| namegenbyai wrote:
| nah, just introduce Scrum, Jira and Miro. Sprinkle with
| microservices and your're done. No one will question anything.
| lemonlime0x3C33 wrote:
| This was a depressingly accurate view of my limited experiences
| at large companies :(
___________________________________________________________________
(page generated 2024-06-16 23:00 UTC)