In a large organization where its not possible to talk to everyone informally. And if some dev sitting in a corner downloads his/her favorite framework, nobody will know. Until the dependency lists are compared and someone finds out that this person went off on their own.

Don't get me wrong. I have no problems with the informal processes if you work in a tiny shop (maybe a dozen developers). But you aren't likely to have a 'devops' position. It will be a part time task of one of the devs. Or the admin person who does the job for all systems (devel, test, production).

But if you are installing stuff, even on your own workstation, you are doing an admin's task. And that means understanding the impacts of your actions upon your and your group's work product. At some point, your company might be asked by a customer to adopt some sort of process standards (think SEI-CMM, ISO 9000, etc.). That will either mean a manual process you must follow to make changes to the development/test/deployment environment. Or turning that responsibility over to a person assigned to to so (that means turning your workstation admin over to them). And I imagine that if the response to this is, "I don't wanna!", the boss will quietly show you to the door.

Was the building not built per the drawing? If this is the case, the building inspectors should have caught it and it was their error. If LeMessurier failed to specify structural details accurately or allowed the contractor to pressure him into an inadequate design, it was his (the engineer's) error.

Clancy touched upon the rumor that nuclear materials made it from the USA to Israel. There is also a rumor that the transfer included technology and designs and a few working warheads just to get them up and running quickly.

The premise of Clancy's novel is highly unlikely. We don't officially acknowledge Israel's possesion of nuclear weapons. But if one was lost in hostile territory, if Israel didn't go in to recover it, we would. It wouldn't serve global politics well to find US part numbers in an Israeli bomb.

Sonds like he forgot to account for systematic risk. Mutiple failures caused by one underlying event having a higher probability than unrelated failures. Its a common problem with the quantitative approach to analyzing failures.

You might niot have parsed the summary correctly. LeMessurier, an engineer, did the structural design. An undergraduate architecture student caught the error.

How do they offshore IT jobs and address security concerns at the same time?

I've seen a number of indoor hydroponic installations. They all seem to have gone to LEDs. And these are for food production (exotic herbs, vegetables, etc.). What with the big money in pots grows, the extra investment should be a no-brainer. So much for the heat signature giving the location away to thieves or the local constables.

Yeah, I've heard the arguments that LED lighting isn't 'natural'. But some of the food farmers using these are on the cutting edge of holistic organic naturaopathic bullshit. And they don't seem to have problems with it. Stuff grown for sale to the local highscholl stoners should be a no-brainer.

Cheap solution

Voyager 1 replies, "What do you mean 'we'?"

Pursuant to your request that I enter into arbitration in place of a civil suit, I kindly refer you to the response proposed in Arkell v Pressdram

... by Korean shipbuilder ...... Hmm. On second though .....

Everyone knows that life was started when inanimate matter was touched by His Noodly Appendage.

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?

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.