Live data from Hacker News

Simple sabotage for software (2023)

erikbern.com

51–60 of 83 posts

Re: Simple sabotage for software (2023)

#51
post #34

Earlier quoted context omitted.

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

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?

You missed https://news.ycombinator.com/newsguidelines.html:

> If you flag, please don't also comment that you did.

Re: Simple sabotage for software (2023)

#52

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

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.

Re: Simple sabotage for software (2023)

#53

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

Re: Simple sabotage for software (2023)

#54
post #17
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.

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?

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.

Re: Simple sabotage for software (2023)

#56

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 don't need that functionality, you need Ruby on Rails and a cold shower.

Re: Simple sabotage for software (2023)

#58
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…

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

Post reply on HN