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.

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.

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.

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.

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

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.

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.

After listening to the kids for a while, all she says is, "Don't make me pull over and come back there!"

Try days or a week out where I live*. Nobody riots. Everyone has a camp stove and supplies. Many of us have gensets and don't even notice the flicker when the power goes down.

The local power company no longer has the staff to maintain their own system. Its all done by contractors or surrounding utilities sending in help. And I don't live in some backwater hick town. I can spit on Bill Gates' house** from my place.

*No cyber attack required. Rotten poles fall over. In fact, we could never tell the difference between a major terrorist attack and normal utility operations.

**Having worked for electric utilities in the past, I am shocked and surprised at the poor shape their systems are in. Even right out in front of Mr. Gates modest hovel.

Many SCADA systems are inherently bi-directional. Some controller monitors system parameters. It then returns feedback to control the processes. Or it forwards them upstream for human attention and intervention.

You could try to 'air gap' such a system from the Internet. But the guy carrying a laptop around to update PLC firmware is going to use it to check his company e-mail. And eventually, the CEO is going to send out one of his/her missives company-wide over the cocktail lounge WiFi at the golf course. Now you're screwed.

Air gaps didn't do Iran much good against StuxNet.