On Taking a Configuration Management Position?

Bravo_Two_Zero asks: "I've recently been offered a Configuration Management position as a lateral (with a slight incline) move. I'm darn happy as an admin, and my heart really lies with system engineering rather than the more mundane operational concerns. But, the position is new, so I would have a chance to define many parameters. Also, it could lead to a management opportunity (if I'm interested) much faster than my current admin slot. It's a hideously complex environment, but I already live through that as an admin. Mileage will vary widely, I know, but I was hoping there might be a school of thought or two from some devoted Slashdot readers who perform or have performed the position. What did you do, and what would you change? And, to the broader audience, is this something you think of as a growth field, or is this just another layer of administrivia foisted on us by an unrealistic development model? Is there a book or other resource that professional Configuration Managers consider a must-read?"

Comments

Proliferation of Options

[jfdawes]

There's so many different development environments, servers, languages, libraries, protocols and file formats out there (and more every day) that any project is likely to run into several new ones.

A huge problem with most of the newer ones is that they are half baked. When you run into a problem you can take days to sort it out: There's little documentation and what there is does not go into any depth, no-one is talking about it and if they are they most likely saying "I've got this problem no-one knows anything about, help"

In this sort of environment, a good configuration manager could be priceless.

(Come to think of it, I keep running into this Java configuration problem with WebSphere: log4j and struts want to use different, incompatible versions of commons-logging. Any ideas?)

Re:Danger, Danger Will Robinson

[SpaceLifeForm]

More likely, it's a huge mess that needs to be straightened out. Having been there, if it truly is a mess, you are talking potentially years to get the CM functioning properly. In this day and age, management does not have the patience to do things right, they want instant results. So, before you take the position, you need to find out how screwed up the situation is already, and then tread lightly.

Depends

[duffbeer703]

I received a similar "promotion" in an environment where the level of fucked-upness is extreme... everybody is accustomed to doing whatever and sees me as a pain in the ass (at best). It really sucks.

I was a system manager at an older company, which translates to a sysadmin who also was in charge of the datacenter and people in it. So I had to deal with HVAC and shit like that. That job was great, I had a team of 15 people of novice-intermediate skill levels who were highly motivated to learn and not get paged at 1AM. I left for more money, and it was the biggest mistake that I ever made.

YMMV.

Avoid resistance your first time out

[ebh]

I've been a CM engineer for a bit over 10 years.

CM is not synonymous with version control (and version control is not synonymous with CVS). Testers need to be able to verify that they're getting exactly what they're supposed to test, no more, no less. Release engineers (the folks that prepare the final distribution media) have to be sure that all the right parts are in all the right place before they start burning CDs. System engineers need to be able to verify that developers haven't given in to feature creep.

But developers naturally don't want to have to deal with any of that. They want to write their code then move on to the next thing. Checkins, checkouts, bug tracking, requirements tracing, 100% reproducibility forever, these are things that developers tend to see as impediments. This can be especially true if your development staff, while good coders, are not conversant in the accepted practices of software engineering (as you'll often find with new graduates).

Ideally, for your first CM job, you shouldn't have to fight these battles. Go into an organization that already accepts that CM is a necessary part of software development. Even better, try to join an existing CM team that already has a good process in place. Then, you can learn what CM really is, how to do it right and keep the most people happy in the process. After that you'll be better prepared to establish good CM in a company with an immature process and headstrong developer-kings.

It's all obvious ... to a point

[nosfucious]

Random thoughts:

Just one rule, get the highest person available to sign off on your rights and responsabilities. If no one higher that your direct boss will do it, forget it. (Minor variations: when you're part of a small team, but if you're big enough to nead CM, that's generally not a problem).

As a guideline: Who, what, why, where, when. Answer those and you'll have a pretty good idea if you're being set up for a fall. As I said, get signed.

CM is part of the so-called quality control. Who owns the quality process? Is is part of audit? Audit is a pretty powerful weapon to use. This mainly because it goes to third parties, like shareholders, stock market, tax authorities and the like. There's not a manager alive that wants thier name put down as the reason your company/department failed an audit.

Alternatively, if configuration is part of your company's "product", then it can also be seen as part of reducing helpdesk and support costs. (Then get the best creative accountant in the company to help you book so called 'revenue' to your cost center).

As part of my scope, I'm 'CM' workstations and server. This is both hardware and software. And I'm allowed to get this right before there is a roll out. My juniors have to follow the CM guidelines or they fix problems because of it on thier own time. Exceptions to the official spec have to be documented and approved (and does happen from time to time).

Then sell your processes to the other project managers. Point out that actually following your guidelines will help them. For example: no fucking around installing new packages in addition to their own installation (because it's already done and already works), etc, etc. New software that works and is supported from day one, looks a lot more professional that one that has bugs, doesn't have the required support programs (Java version, DLL, Office Version, etc) and helpdesk training (you do have documents and training for your helpdesk?).