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