Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple sabotage for software (2023)

erikbern.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Simple sabotage for software (2023)

#71

Post by hamstergene »

lemonlime0x3C33 wrote: post #60

This was a depressingly accurate view of my limited experiences at large companies :(

Not sure about the entire list, but I've seen 4 of those many times. They are common techniques of impostor-employee to fool an impostor-manager:

1. A person who knows little of the topic assumes that talking a lot means knowing a lot. Hence long ChatGPT-like speeches. This has been my personal number 1 red flag since long before LLMs became a thing.

2. An incompetent manager is helpless in a situation when "everybody screwed up a little bit" as they don't pay attention to ownership or don't even understand its importance. Hence creating groups/committees to blur personal responsibility.

3. "Bring up irrelevant issues" is natural consequence of not understanding the topic very well, combined with forcing oneself to take part in the discussion. Pretty sure it's not even intentional. But either way, it's irrelevant from your point of view, but not from the the manager's, so it works.

4. Advocate caution at everything is because if the team screws up and attracts attention from higher ups, people at the most risk will be the lowest performers and the manager. It's a shared interest.

Re: Simple sabotage for software (2023)

#72

Post by roenxi »

krisoft wrote: post #10
roenxi wrote: post #5

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 o…

> 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 talk…

> You are talking about the strategy “working” or “not working” as if these are binary things.

WWII was before all this, but we have decades of management experience about how to take ordinary people and make them productive in an industrial setting.

The CIA list isn't the inverse of that. They didn't have Dilbert then either, but it looks like the equivalent of mailing over some Dilbert comics. Maybe it is better than nothing and I don't fault them for trying everything but I've never seen evidence that these are actually effective hints at sabotaging an organisation. The office-work stuff, not the physical ideas which I assume are quite effective.

Now that the discipline exists it'd be interesting to get a group of great operations researchers together and have them come up with their own list of ideas then see what the overlap is. It might be quite small. Is it more damaging to have a great worker who gets one or two key thing wrong or a grumpy guts who does poorly at everything? I suspect the former, the sabotage handbook the latter.

Re: Simple sabotage for software (2023)

#73

Post by Spivak »

KronisLV wrote: post #18

> 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 K…

The way I think about this without going insane isn't "developer environment must be exactly the same as production environment" because like you said, you'll never do it — there's too many things you can't replicate locally.

So I flip it around — production should work exactly like the development environments. If there's a a difference between the two that matters we update production to match. You want to talk to other services by a well-known container name instead of an env var we pass? Sure, whatever we can do that.

Re: Simple sabotage for software (2023)

#74

Post by smcin »

krisoft wrote: post #64
_djo_ wrote: post #44

Earlier quoted context omitted.

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

That is what I mean exactly. Your second sentence answers your question. My dad is not me. The OSS is not the CIA. It is a predecessor of it.

Feels too hairsplitting. It was the same type of people doing largely the same activities with the same objectives, even if on paper there was a 2-year hiatus between OSS being dissolved and CIA created. People would understand if you wrote "OSS/CIA did X" when describing the 1940s/50s/60s.

Similar to how a branch of the US Public Health Service [0] originally tasked with malaria prevention became Communicable Disease Center (CDC) in 1946-67, subsequently renamed to "Center for Disease Control" and "Centers for Disease Control" (1980), "Centers for Disease Control and Prevention". It hasn't actually been called the "Center for Disease Control" since 1980, although many people (incl. journalists) still call it that.

Also, most countries' Department of Defense/Ministry of Defence were called Ministry of War or Department of War during WWII (and some only controlled the army, not all branches of military). [1] And the White House War Room was renamed the Situation Room in 1961. (RIP George Carlin.)

[0]: https://en.wikipedia.org/wiki/Centers_for_Disease_Control_an...

[1]: https://en.wikipedia.org/wiki/Ministry_of_defence

Re: Simple sabotage for software (2023)

#75

Post by [deleted] »

patrakov wrote: post #29

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.

[deleted]

Re: Simple sabotage for software (2023)

#76

Post by nerdponx »

Successfully carrying out even 1/3 of this list would scare off competent contributors who weren't completely desperate for a job.

The article kind of missed that detail, but this form of sabotage doesn't even need to be that effective to deeply sabotage the organization/product, it just has to be bad enough to scare off good talent and keep turnover high. The stuff in the "hiring" section makes it even worse by preventing good people from even getting in the door in the first place, but eventually a company like this would be scraping the bottom of the barrel for candidates even without deliberately bad hiring practices.

Re: Simple sabotage for software (2023)

#77

Post by nerdponx »

oopsallmagic wrote: post #53
photonthug wrote: post #21

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 fi…

"Never attribute to malice that which can be adequately explained by stupidity."

Except when there's a financial incentive. Never attribute to stupidity what can be adequately explained by greed.

Not sure if there's a name attached to this counter-principle, but it's just as important as the original in my opinion.

Re: Simple sabotage for software (2023)

#78

Post by maxbond »

krisoft wrote: post #65
hinkley wrote: post #27

Earlier quoted context omitted.

The head of the OSS also founded the CIA, so is it really that big of a stretch?

> is it really that big of a stretch? I don’t know what is a big or a small stretch. I just know it is just not true. If you studied the history of the second World War, or the history of the CIA, or the history of the Cold War then that sentence sticks out like a sore thumb. It makes as much sense as describing how many Gatling guns Hannibal mounted per elephant. I guess in a certain post-truth sense it is a smaller…

I think you overstate. It's an ellision ("written by OSS, the predecessor of the CIA" to "CIA"). They're as common as weeds and as old as the hills. It's all well to point out that it's factually inaccurate, but it's directionally correct and gives people who aren't familiar with OSS the right impression. You don't have to like it to recognize it isn't a "post truth" phenomenon or anything comparable to Hannibal crossing the alps with Gatling guns, or even that the document was authored by the KGB.

Re: Simple sabotage for software (2023)

#80

Post by kmoser »

> Deploy as infrequently as possible. Urge extreme caution about deployments. Leverage any production issue as a reason to “pull the brakes”.

Deploying infrequently doesn't necessarily sabotage things if it results in well-written and tested code before deployments, which tends to create stable systems. If anything, it's the opposite of "move fast and break things." If you want to sabotage things, urge frequent deployment and minimal testing.

Post reply on HN