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

21–30 of 83 posts

Re: Simple sabotage for software (2023)

#21

Post by photonthug »

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.

Re: Simple sabotage for software (2023)

#22

Post by fuzzfactor »

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…

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

Re: Simple sabotage for software (2023)

#24

Post by teddyh »

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…

Im some ways, this is an unsolvable problem, due to entropy. You can’t even step into the same river twice.

Re: Simple sabotage for software (2023)

#26

Post by lelanthran »

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?

Re: Simple sabotage for software (2023)

#27

Post by hinkley »

krisoft wrote: 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.

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

Re: Simple sabotage for software (2023)

#28

Post by hinkley »

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…

I used nginx as a forward proxy a couple times before Docker was a thing. Poor man’s service mesh still has some utility.

Re: Simple sabotage for software (2023)

#29

Post by patrakov »

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.

Re: Simple sabotage for software (2023)

#30

Post by btbuildem »

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.

Post reply on HN