Live data from Hacker News

Simple sabotage for software (2023)

erikbern.com

31–40 of 83 posts

Re: Simple sabotage for software (2023)

#31

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?

You build 9 different services in-house, obviously.

Re: Simple sabotage for software (2023)

#34
post #7

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

> 4. Bring up irrelevant issues as frequently as possible.

Excellent. Continue the good work.

Re: Simple sabotage for software (2023)

#35
post #8
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…

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.

Doing what? Getting paid by a competitor to destroy his current company?

Re: Simple sabotage for software (2023)

#37
post #11

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.

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.

Re: Simple sabotage for software (2023)

#38
post #34
post #7

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

> 4. Bring up irrelevant issues as frequently as possible. Excellent. Continue the good work.

Let's keep talking about this. How is two years "several"? That's "a couple" literally and maybe "a few"

Re: Simple sabotage for software (2023)

#39
post #8

Earlier quoted context omitted.

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.

Doing what? Getting paid by a competitor to destroy his current company?

No, being incompetent to the point where if you squinted he might as well be.
Post reply on HN