Everyone knows that life was started when inanimate matter was touched by His Noodly Appendage.
Devs can do whatever they want on their local workstation. In any given week, I work on 2-3 different projects with radically different stacks.
What is the end product of this work? Source code?
If you produce source against a particular 'stack' (API, library version, framework, whatever) how do you know that the people next to you are using the same ones? And that the various modules your group produces will even build or link together? What happens if the guy in the next cubicle says, "This Dynedain guy is using the wrong version or fork of {whatever}. I'm going out to download and install the latest or the best and build my components using these. And if his stuff won't link with mine, tough." Who would stop him?
They don't have the ability to install any dependencies or configurations on stage, so if they run into problems, they need to negotiate with DevOps. QA validates on stage and has client do UAT on stage.
So, you wait until the sh*t hits the fan and then DevOps comes looking for whoever used the wrong tools or build configuration. The guy in the next cubicle says his favorite framework is better and that Dynedain guy needs to suck it up and redo all his work using the 'correct' environment. Antics ensue.
Somehow, I don't think your organization is going to score a very high SEI-CMM level. Forget ISO 9000 certification.
I assume you have various individuals/groups who have an interest in the systems you administrate. Users, developers, etc. Also regulators. Don't forget the utility of a good documentation system when the auditors come around*. So you need a process to keep them informed of the upcomming system changes. So they can ensure that their product or process isn't going to be broken by a change.
If you have relatively few of thes interested parties, the communications could be mandles manually and by you. If that community is large, the procedures need to be formalized and possibly automated. Having a CAB to represent your user community can offload the communications task from you. At the expense of some paperwork.
On the other hand, I've worked in organizations where the CAB was a make-work task for a few layers of management. People whos only other job prospects are standing by an off-ramp with a cardboard sign*.
*At one of my previous jobs, this was the acid test of the utility of our CAB. I had to fill out stacks of paperwork and await their blessing to make a change. But strangely enough, whenever the FAA came around, they were nowhere to be found. I had to walk the auditors through our systems myself.
I thought this was something we could use to exterminate all those smug bastards yakking on phones while driving or in line at Starbucks.
The least they could have done was to pony up for some Google Glass.
At least the homeless could have pawned them for some spending money.
Thank goodness that never came to be, #37809.
Why in the hell would anyone be working on production code on their local machine?
As a developer, what do you think your job is?
We may be suffering from a terminology problem here. I think developers produce code as their work product. Which is turned over to a build environment for subsequent testing and finally installation.
If you have a different job description for a developer, I'd like to hear it. I wouldn't hire it, but I always get a chuckle out of projects that are so deeply layered that there are people which we don't really know what they do.
But somehow you've extrapolated that into Devs not having admin privileges on their local workstations which is absurd.
If you produce anything that affects the configuration of the final product, it had damned well better be under configuration control. And that means your administrative 'privilege' is restricted by some processes and procedures. If you have them at all. That's the way its done in avionics, medical, financial and a lot of other software houses. If you are just hacking out games, then who cares? Fiddle with your development environment all you want.
Devs should have admin access *on their local machines* so they can evaluate libraries and platforms.
No. Not if they are working on production code.
There is a project phase for testing tools and libraries. But even then, the installation for this evaluation should be done under configuration control. Or each dev could end up with a custom environment that doesn't properly reproduce code across different machines. The installation/configuration of these tools needs to be done by people with admin skills that lead to reproducible results across the entire dev team should that product be selected.
Too many developers here are crying about not wanting to have administrative responsibility. But try taking the admin privilege away and listen to the screams.
I hate to break the bad news to them. The only people that will be making a million developing s/w will be making a million rupees.
Road side illumination should be generally restricted to built up areas and be more about restricting nefarious activities rather than traffic safety.
Agree. But now you will run afoul of the AARP. Old people don't see well in the dark. And in the USA, until they actually need the white cane and dog, you can't take their license away. The megawatts of wasted lighting we install in this country is to keep the geezers in their Cadilacs.
As to the 'nefarious activity', that PR was created by the power companies trying to sell street lighting. Most criminals prefer to hit during the day, when they can see.
FTFY.
Think of it this way: Your kids are geting a head start at Harvard Business School.
But that's why you have an admin group responsible for your workstation (instead of you having admin rights). Maybe there are "an insane number" of goodies you'd like to play with. But if you cause problems for people downstream, the answer should be, "No."
does not mean Ruby needs to be installed on the production environment. That's what build servers and deployment scripts are for.
So you should cause the admins responsible for the build environment to chase after your particular suite of toys? I don't think so.
So few developers have a good view of the s/w lifecycle that they either need their admin rights taken away or they need to spend some time in DevOps (administration, whatever) so they can see the PITA that their work habits cause.
I've worked in companies (aviation related, where you'd think config control would be taken seriously) that were continuously 'infected' by tool vendors slipping some developer a 'free' s/w CD at a conference. Knowing full well that once their work product made it into the production environment, thousands of licenses would have to be bought or their crap would have to be backed out. And I've seen developers throw screaming (literally) tantrums about taking their toys away to the point that management backed down.
One s/w vendor's game was actually written about in the Wall Street Journal some years ago. About how they slipped a few copies of their product into my employer and caused them to have to buy millions of dollars worth of licenses for the installed product.,
The best developer is one who puts stuff together that 'ops' people (users, admins, etc.) can work with. And the best way to get such developers trained is to give them some experience on the other side of the fence. Yes, in a large organization there is going to be less crossover. But its still a good idea. Some people won't like being admins. Some will really take to it. Its up to management to properly allocate resources and keep their people trained and familiar with adjoining organizations needs.
If you absolutely don't want to do any administration tasks, that's fine. But its a rare developer who doesn't throw a fit when management takes their admin/root privileges away on their own workstation.
I work for a water utility
Public or private? That makes a lot of difference. Public utilities tend to take more responsibility for the collateral aspects of their mission than private organizations.
My local power company was a publicly traded corporation. That was bad for anything they didn't consider to be a 'profit center'. But then they fell on hard times and were taken private by a consortium of utility service providers (contractors, outside IT and engineering outfits). The core utility profit margins are kept tight by the state regulators. But the pass through charges from the contractors (unregulated) is still highly profitable. The utility is being kept on life support for the benefit of the contractors.
The remaining shell company may in fact take their security responsibilities seriously. But they are being squeezed between regulators trying to keep prices down and their vendors who sell them old technology, insecure systems. Because the new ones are expensive when provided by the vendors and there isn't enough utility staff left to do the job in house.
Only through hard work and perseverance can one truly suffer.