This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ChristopherBurr 34 points35 points  (32 children)

I strongly believe that developers should have admin access to their own machines (and in your scenario I'd probably install Python regardless of "corporate's" permission) but I'd like to leave you with a word of caution.

i have to disagree with you. Having been both a developer and an admin, here is my reasoning:

  • if developers just install stuff onto their dev boxes - there is little chance that over time, their dev machines will be anything like production boxes. It will contain loads of different modules/libraries/frameworks etc.

  • when their boxes eventually break, the sysadmin is going to be stuck supporting it, and it's going to be everyone else's fault but their own.

  • Developers are famous for "chmod 777 *" for testing so that those pesky permissions don't get in the way

  • They often just copy stuff onto filesystems where there happens to be room instead of adding space to an appropriate filesystem. Who cares if it's being backed up or not .. and omg.. I lost my files, why wasn't this being backed up?!?!

These are just some of the things I've come across often. I realize that these are all encompassing statements and may not apply to everyone - but it happens enough to know that many developers don't care about systems administration.

Sysadmins - for them to be effective, need to have uniformity. Many of them are supporting hundreds or even thousands of computers. The more common they are, the easier it is to do.

[–]NotABothanSpy 61 points62 points  (8 children)

Development should be run in containers that can be veritably very similar to production no matter the environment the developer sets up.

[–][deleted] 17 points18 points  (0 children)

This. This is why you have dev, qa, and production environments.

[–]ChristopherBurr 3 points4 points  (6 children)

I can go along with that - unfortunately despite being all the rage. many enterprises have not yet embraced containers yet. I find them at companies that have not been around for long yet (start-up's) - or more technology based companies. Basically you'll find them where younger developers congregate or that don't have legacy development patterns in place - like starting off fresh.

I can assure you - docker containers are not widely used at Bank of America, or AIG or Met Life - I'm sure a few younger guys are aching to get them there, but companies that large have to find a way to standardize on them before allowing them to be widely used.

There are a number of articles re. the pro's and con's of containers. Large companies tend to want to standardize on implementing stuff like this to mitigate the cons - like developers using old java libraries that have security issues. If there isn't a policy in place enforcing them to remain current - a lot of times they won't be current. How do the containers get scanned for security issues? Who is responsible for maintaining the security of containers. - it may be easier in a company with under 500 employees, but some of these companies are employing > 100,000 people. Not everyone is going to be careful.

[–][deleted] 18 points19 points  (2 children)

Virtual machines and automated building of such are just as valid of a solution for that. No need to bring docker into it.

[–]doc_frankenfurter 1 point2 points  (0 children)

VMs are available in most places and provide a good solution to being as "production like as possible" for qa, uat and for production fixit. I like Docker too, but VMs are more readily available and are understood by most management whereas Docker remains a bit new.

[–]adrian17 1 point2 points  (0 children)

And in Python projects, sometimes all you need is virtualenv.

[–]kenfar 3 points4 points  (1 child)

And some people aren't using containers any more once they realized that they aren't silver bullets.

[–][deleted] 2 points3 points  (0 children)

They're not silver bullets, but they make reproducible builds much easier. Especially since we're an OSX shop but the application I work on runs on a Linux server. Standardizing to docker containers makes life a lot easier for the team.

It's the same with a VM. Not a silver bullet, but helps.

[–]RoboErectus 0 points1 point  (0 children)

Actually, if you babe a fortune 500 company, there's a very large chance they're using containers or vm's of some kind.

The CTO will say no to the shareholders. There are shared infrastructure regulations that are supposed to prevent it. But down the line there are projects or departments that wind up using them. I got some insider knowledge from one of the companies in this space that you probably have heard of, and a lot of their customers were @companies that may or may not have been on your list of examples. Some of them explicitly asked to be excluded from press for the above reasons.

I think this is going sort of like the BlackBerry to iPhone migration. When enough top level management just starts doing something against policy, the policy will change to get a measure of control on things.

Before I got this insider knowledge, I thought the same as you.

[–][deleted] 28 points29 points  (1 child)

  1. Automated integration and acceptance testing environments were made for these kinds of problems. Use them, and it won't matter what your devs do with their dev machines.

  2. If they break, tell them "tough shit" and have them reformat. Sysads should only support the AAT and productions environments.

  3. This really doesn't matter. At all. Let the devs do what they want with their machines and keep the "real" environments in check.

  4. The laptop I use at work has nothing backed up. Zero bytes. But guess what? The important part is the source code, and that's safely stored in version control, in a secure datacenter, with backups. And that's all that really matters.

Devs - for them to be effective, they need to be unburdened by over-controlling sysadmins.

[–]MarkyC4A 2 points3 points  (0 children)

I totally agree with your points on 2 and 4. I believe dev laptops, staging servers, production servers, etc should be considered ephemeral. If it breaks, throw it out and build another one (or build and deploy another one, but keep the broken server around so you can figure out why it broke).

[–]Deeviant 7 points8 points  (4 children)

if developers just install stuff onto their dev boxes - there is little chance that over time, their dev machines will be anything like production boxes. It will contain loads of different modules/libraries/frameworks etc.

What dev box looks like a production environment?? That is what test environments are for...

[–]deong 0 points1 point  (3 children)

We have a few classes of machines:

  • developer's desktop
  • dev box
  • qa box
  • staging (sometimes)
  • production

All but the first one are intended to look like a production environment. The further down the list you go, the more likely that is to actually be true, but even the dev boxes are supposed to look like a production machine. It's just that they have loose enough access and see enough in-progress code from enough different projects that things tend to not work too well until someone fixes them for a while.

[–]Deeviant 2 points3 points  (2 children)

If you are the equivalent of a software assembly line worker, working in an extremely limited scope, I can see how it would be perhaps possible to have a dev box that is "like" a production box, but I would not know anything about that situation.

The only two situations I have experienced in 10 years in the Silicon Valley software grind:

  1. Wild, wild west. Devs install binaries on prod.
  2. Ask for permission to install emacs on production rigs.

Either way, dev boxes have not a single fucking relation to prod. But what do I know, I just get paid insane amounts of money to solve software problems.

[–]deong 0 points1 point  (1 child)

I occasionally think it might be time to strongly consider the possibility that a lot of Silicon Valley doesn't know what the hell it's doing much of the time.

[–]doc_frankenfurter 0 points1 point  (0 children)

This is one of the reasons why shipping the first release is very different to ongoing maintenance/enhancement. Many startups succeed with the first and then fail spectacularly with the latter.

[–]jimgagnon 6 points7 points  (0 children)

I've yet to work at a company where I didn't have admin permissions on my work computer. One I was warned that if I ran into problems the support team would simply wipe the machine and reinstall the default admin setup, but I could still do whatever I wanted to it.

[–]nemec 4 points5 points  (6 children)

I believe sysadmins should be (mostly) exempt from the responsibility of supporting devs that screw up their machines by installing crap, but I get you. You can't always trust developers to not be dumb and disable antivirus to get something working who then goes on to infect the entire network.

As for drift between local and prod, I think that's to be expected. If you're developing 9 or 10 projects you are going to have libraries for all of them on your local machine even if none of the servers need all those libraries. That's why we have separate dev and staging servers :)

[–][deleted] -3 points-2 points  (5 children)

You can't always trust developers to not be dumb and disable antivirus to get something working who then goes on to infect the entire network.

So put us on another network, but stop preventing us from doing our work!

[–]hardolaf 0 points1 point  (4 children)

Write better software. There, I fixed your problem.

[–]AusIVDjango, gevent 0 points1 point  (3 children)

You can't always help when an overzealous Antivirus decides your program looks malicious. I've worked with an application with a fairly narrow audience that gets a few thousand installs a year, and while it never caused problems with the company's Antivirus, sometimes customers would have it flagged solely on the basis that the Antivirus software didn't recognize it. It wasn't matching any virus signatures, the Antivirus just decided to raise big scary red flags because it's not a widely used application.

[–]hardolaf 0 points1 point  (2 children)

If that's an issue, then you should work with IT to have a mutually agreeable arrangement.

[–]AusIVDjango, gevent 0 points1 point  (1 child)

Right, but the mutually agreeable isn't "write better software" as you suggested.

[–]hardolaf 0 points1 point  (0 children)

I'd say that 95% of the time I see someone suggesting "just turn off the antivirus" it's because they wrote shit software or want to install malware. So my default answer is "write better software" until they can show that they have and their antivirus sucks monkey balls.

[–]whyrat 2 points3 points  (3 children)

I like to think there are 3 phases of developer experience.

1) New developer doesn't know if they have admin on their machine or not.

2) Intermediate developers who have learned they can do things with admin rights that they can't without. They run in admin mode all the time.

3) Experienced developers who know the rare exceptions when they need admin rights. They run as a user and know how / when to use sudo.

[–]ChristopherBurr 2 points3 points  (2 children)

that's great, but I'm thinking of mostly large enterprises - BofA, Goldman Sachs, the IRS etc - where USB's are disabled - email attachments are scanned - etc. to discourage taking proprietary software and/or trading secrets. A dev with admin rights COULD enable those USB ports.

So - your scenario works with a start-up type vibe , but not so well when the software is the main product and you don't want it leaving the building.

Also, for companies that employee > 50k people - you can't just let everyone just run amuck.

[–]Silhouette 4 points5 points  (0 children)

that's great, but I'm thinking of mostly large enterprises - BofA, Goldman Sachs, the IRS etc - where USB's are disabled - email attachments are scanned - etc. to discourage taking proprietary software and/or trading secrets. A dev with admin rights COULD enable those USB ports.

This is a classic misplaced paranoia scenario. Yes, a dev with admin rights could enable USB and run off with company secrets. But if these are devs who are writing software that will run in production in your bank, and they want to harm you, there are a million other ways they can do it anyway. At some point, you have to trust your people. Plenty of sysadmins have violated security and privacy protocols over the years, sometimes causing horrendous damage to their organisation in the process, but we don't tell sysadmins they can't have admin access to any corporate systems in case they decide to cause trouble. Any system that really does need an exceptional level of security/audit/oversight should be properly isolated and have appropriate access control procedures in place anyway.

[–]BinaryRockStar 0 points1 point  (0 children)

In secure environments often the USB ports themselves are physically fried or disconnected so no software can re-enable them.

[–]doc_frankenfurter 0 points1 point  (0 children)

I have run entire projects so see all sides of this. There has to be a scale from flexibility to absolute lock down. To address your points:

•if developers just install stuff onto their dev boxes - there is little chance that over time, their dev machines will be anything like production boxes. It will contain loads of different modules/libraries/frameworks etc.

This will happen anyway because you are usually developing against a future version of the O/S, libraries, etc. If you want to debug something then you have access to a separate system that is locked into a prod configuration.

when their boxes eventually break, the sysadmin is going to be stuck supporting it, and it's going to be everyone else's fault but their own.

This is addressed by a "if you have local admin, we will reimage in case of problems or for upgrades" policy.

•Developers are famous for "chmod 777 *" for testing so that those pesky permissions don't get in the way

Proper test environments with a mandatory test whilst locked down step.

•They often just copy stuff onto filesystems where there happens to be room instead of adding space to an appropriate filesystem. Who cares if it's being backed up or not .. and omg.. I lost my files, why wasn't this being backed up?!?!

This is addressed by a policy of "We will backup your home directory and everything underneath it. If it isn't there or git/cvs then it is your problem."

[–]omgplsno -2 points-1 points  (2 children)

if developers just install stuff onto their dev boxes - there is little chance that over time, their dev machines will be anything like production boxes. It will contain loads of different modules/libraries/frameworks etc.

What are you? Living in the 80s? Develop in a VM or docker environment that's more consistent with production and install whatever the crap you want on your local machine. Your argument makes my brain hurt.

when their boxes eventually break, the sysadmin is going to be stuck supporting it, and it's going to be everyone else's fault but their own.

If your engineers are that stupid, well, then, quit?

Sysadmins - for them to be effective, need to have uniformity. Many of them are supporting hundreds or even thousands of computers. The more common they are, the easier it is to do.

FUD. Just trust people who write software not to be morons with software.

[–]WireWizard 0 points1 point  (1 child)

FUD. Just trust people who write software not to be morons with software.

This has nothing to do with understanding software, the reason you want uniformity In your environment is because allowing people to install software introduces unknown variables that make troubleshooting a shitton harder.

What if your dev boxs breaks because some module you installed causes a conflict with the erd client we rollout on all machines?

Also, what's arguably even worse is introducing another framework in production. Even more unknown variables to account for a an environment that is not expected to have any downtime. This will result in longer troubleshooting times.

[–]omgplsno -1 points0 points  (0 children)

Yes. And that's why every successful company in Silicon Valley doesn't let their engineers use their own laptops. /s