4 ms·
Standardizing a set of supported tools inside an organisation isn’t exactly a stupid corporate protocol, especially if it’s a very large organisation.
by AmericanChopper 7y ago
Standardizing a set of supported tools inside an organisation isn’t exactly a stupid corporate protocol, especially if it’s a very large organisation.
- xenonite 7y agoA hammer is not always the best tool. Edit: what did you mean by "a set" of standardized toosl? Like the set {Windows 10, Linux of some distribution, macOS 10.15, iOS, Android}? Even then, what if some app does not work on Windows 10? Or what if you need a 32 bit app running on macOS?
- AmericanChopper 7y agoBut if your 10,000 employees each need a hammer, getting them all the same one, from the same vendor, with the same support contract might just make sense. Edit to your edit: whatever particular sets of tools the business needs. Whether it’s laptops, thin clients, operating systems, IDEs, ticketing systems... > Even then, what if some app does not work on Windows 10? If your business had standardized on Windows 10, then you’d hope checking whether things worked on Windows 10 would be part of their procurement process. > Or what if you need a 32 bit app running on macOS? You choose something else. Like any business running MacOS would have to do.
- xenonite 7y agoAnd then there are some with very small or very big hands. Would you give them a different hammer, or would you criticize their subpar performance?
- AmericanChopper 7y agoI’d probably just pick a better analogy. If the job can be done on the operating system provided, then it can be done equally well by anybody using that operating system. No need to grow bigger hands.
- xenonite 7y agoThe analogy is perfect in my opinion. Like the body, everyone's brain is different.
- AmericanChopper 7y agoIf you’re working from the premise that your brain is only suited to work with one operating system, then you’re really only harming yourself, by shutting down any opportunities you may otherwise have open to you. Small organisations have the luxury of letting people choose their tools more freely. As they grow, they tend to have to restrict this more. Not just because they might have to support the tools you choose to use, but because they absolutely will have to support how your choices work with all the other tools they have in the organisation. At scale, this starts to get out of hand pretty quickly, and the only way you can provide a good working experience is by adding constraints to the tools used. On top of that, some organisations have regulations and compliance requirements to meet that make it even harder. If your basic procurement pipeline includes $10,000 of vendor due diligence, then you don’t want to just give everybody free reign to use anything they feel like. If those choices introduce additional ongoing compliance costs, then you want to control that even more so. You could ignore all of that, and focus only on how it affects you. But there’s good reasons that organisations do that sort of thing.
- krapht 7y agoI would ask what's going on that couldn't be solved with cygwin or virtual box.
- xenonite 7y agoThis largely depends on the job. Some tasks can even be done with a locked down iPad, some not at all.
- closeparen 7y agoMature IT departments tailor solutions to different classes of users with different needs. If they don’t do that for engineering, that tells you everything you need to know about engineering’s stature in the company.
- AmericanChopper 7y agoTo an extent, and as allowed by whatever particular constraints exist for that business. Letting you run whatever IDE you want, usually OK. Letting you install whatever operating system you want, well... there’s lots of reasons you may choose to not support that choice, that have nothing at all to do with maturity. If your jobs was improving developer experience, there’s only so many times you can come up with solutions that work great for everybody except that one guy on Arch, before you give up.
- loopz 7y agoThis is more related to how organizations work. That larger organizations tend to need to streamline more in order to scale up number of employees, and do more to maintain acceptable security simply because there's that many more people on board. If policy is install whatever you want, and if you get hacked, you're fired! This just won't stand in court. So policy is that IT department is responsible for installations, IT department gets the blame. Infrastructure is sort of "outsourced" within the company. If you were accountable for those younger first-timers running I2P and Tor within security perimeter, what would you do?
- AmericanChopper 7y agoLower down the tread I mentioned vendor due diligence, specifically because I’ve done so many vendor security reviews. But there’s more to it than that. You might also need to be threat modelling it, legal will need to review the ToS and privacy policy. You probably need to figure out the impact on other services too. If you’re in a regulated organisation, there could be any number of other things you have to do, and on going compliance costs. If you work in a bank, and somebody wants to install Gentoo, you’d have to figure out how to run anti-virus on it, how to centralise patches for it, how to install endpoint DLP, make sure it has the correct web proxy configuration... the costs can easily stack up.
- globular-toast 7y agoIt is stupid. There's no room for growth if you standardise tools. What they should be doing is standardising protocols. There's a big difference.
- AmericanChopper 7y agoThey already did. They settled on NTLM. I hope your chosen thing supports it, or you’ll have to pick something else.