Slashdot Mirror
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?"
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?)
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.
You are being MICROattacked, from various angles, in a SOFT manner.
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.
Conformity is the jailer of freedom and enemy of growth. -JFK
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.