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.
About a year ago I struggled with this same question, but my question was to move from a "real" development position at a small company with an uncertain future, to taking a configuration management type position at a large firm (lots more money, lots more opportunities, but in my eyes a demotion).
I am happy I took it. My hours are normal now, im no longer held to killer unreasonable deadlines. I have my foot in the door to management as I manage and "own" many resources and get to make (and enforce) real policy decisions that affect a group of about 50 developers. Im still involved in development, but am generally not neck deep in the coding trenches. If I see a build failed for a reason I can fix, I just fix it. I also get to do those projects that as a developer you were just dying to do if only you had the time- essentially refactoring code on a mass scale- ripping libraries out and putting them in a central organized repository, and things of that nature.
Must Reads:
Configuration Management Principles and Practice (addison wesley)- Do everything in this book. EVERYTHING. Absolute must read.
Software Configuration Management - Wayne Babich
A bit dated, but short and worth a read.
Mythical Man Month - Fred Brooks
A good conf. mgr. needs to understand project management issues on software projects. This book is a classic.
Other advice (if you take the job):
Like any manager, you can be the developer's best friend or their worst nightmare. Processes are indeed important, but you must not make them burdensome. Red tape sucks for everyone, as well as unneeded, redundant and conflicting procedures.
I am very happy with my decision. The only downside I really have is that even people in the tech industry do not know what configuration management is, and often picture you writing ini files or admining. I often just describe myself as a developer, which is somewhat annoying since its not entirely accurate. Organizations that employ configuration managers are recognizing that they cant just rely on developers pulling workflows out of their ass or software solutions to ensure that their builds remain consistent. I would think that as Software Engineering processes evolve, you will see more Configuration Managers in the future.
As we outsource more and more, it is these types of positions that have to remain in house- make cheap offshore developers write all the code for some separate pieces of software and a few on-shore configuration management people make them all work together peacefully.
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
The biggest factor for how you'll do in such a position is not the technical aspect, but rather your personality and temperment. In order to have an efficient and well running system, you must lay down the ground rules and ensure that everyone follows them. This may require you to step on a few toes here and there. And there will be those who get pissed off at you for enforcing YOUR rules on THEIR project. At least that's how they see it. There will be those who think that CM is a waste of time and will put forth the minimal effort to conform. There will be those who ask you for unreasonable services time and time again. If you're okay dealing with the few oddballs and it doesn't bother you to say "No, you insensitive clod!" then you'll probably be just fine. Of course the majority of programmers under you will be reasonable and try to work with you.
The most important thing is to make a decision and not budge from it. If you try to please everyone all the time, you will have a very unhappy existence.
Over the years I've migrated from embedded development to configuration management. I'm more of the geek who handles packaging, versioning, and so on, and not a manager. The biggest problem with this role is that short sighted management doesn't care about these details. While they understand that this stuff has to work right, it doesn't involve any of the features that are on slides used by marketing and sales. The money side of the shop use admin services, so they have a better understanding of system administration than configuration management. Often times I end up being the odd man out. But it also means that as long as everything works right, I'm pretty much free to do things how I like.
When I was laid off a few years ago, I'm convinced that what put me on the list was that nothing I did was on the short term "must get done" list. But to the plus side, I was able to find a job in late 2001 in under 3 weeks. Just because it isn't highly regarded, doesn't mean no one finds it useful.
Another issue with CM is that the packaging issues get interesting at release time. This means you will have to work around schedule slips because this is the last thing done before pushing the software out the door. And there are the endless "could you make a special release before 8am tomorrow" type requests. As an admin you're used to odd hours, but I hope you're not expecting this to be a 9-5 type position.
I'm not going to say if you should or should not make the jump. That is a personal choice and only you can answer that. But I will say that if they want you to do CM with Visual Source Safe, forget it. Life is too short for VSS.
- doug
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.