Hacker News new | ask | show | jobs
by 21asdffdsa12 33 days ago
Because centralized management of resources is the death of innovation, intrinsic motivation and speed?

The dreaded "process" to get a single tool registered, working and allowed, is the reason a company is slow, dysfunctional and usually failing at a task.

The security tax and speeding tickets on everything are a luxury destroying much value.

3 comments

This is the new old way. This was fine before irresponsible use of AI. Between vibe coding and using AI to find vulnerabilities as a result of vibes, I'm afraid that we will have to find ways to have more controlled environments.
It seems likely that some companies where the trade off shifts will head in that direction.

The problem with controlled environments is that even when done sensibly by people with good intentions they do slow things down and a lot of orgs will decide the trade off isn’t worth that.

I’ve worked for companies that did have much more controlled environments but given everything is made of a thousand packages these days and those packages have CVE’s and you do need to patch doing it after the fact is a recipe for paralysis.

Move fast, break things, get internal repository leaked and lose all the 9s.
Im pretty sure GitHub reliability issues are a result of Microsoft centralized management (i.e migrate everything to azure, the only allowed cloud)
Tbh, at this point why does it matter if it was MS or not?
I don’t think it does, I was just pointing out their issues are likely caused by the centralized resource managementent (mentioned by https://news.ycombinator.com/item?id=48219114 you responded to), and not the „move fast, break things“ aspect. Just my guess. But yeah, it doesn’t matter if it is MS or GitHub itself
Your company getting hacked because of random plugins for emerging or dysfunctional ecosystems that don’t have enterprise management solutions yet is worth it to avoid friction?
Yes and no.

The friction they should have probably had here is: did this employee need access to 3,800 internal repos?

I'm with the poster above in believing restricting what you can install makes a lot of things more difficult, but if you're going to take the risk you should be limiting the blast radius.