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.
I believe that in this position, you have to lay down procedures and make sure everyone adheres to them. Keep all documentation up to date and if possible, have checklists that people have to sign off...
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.
CM and quality positions can end up being in conflict with developers, but there's no reason it has to be that way. Try and keep the developers onside as you implement new tools and processes. We sorted out CM here many years ago and while the initial phases were hard on people, the rewards became obvious pretty quickly.
And don't be overly bureaucratic. You're adding red tape to everyone's lives. Do it slowly and be prepared to remove any of it that's not got an obvious benefit. I've worked on projects with very prescriptive lifecycles for changes, for instance, and they're generally unhelpful because there isn't a visible point to following the lifecycle. Similarly, restrictions on what developers are allowed to change are unhelpful; better to train the developer not to change unsuitable stuff.
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
There's another kind of "Configuration Management" in the context of the ITIL framework (IT Infrastructure Library, a very interesting collection of books about best practice in and around IT operations): There, configuration management is more related to infrastructure items (client PCs, servers, printers...) than to software development. You may want to google for "ITIL" or look at OGC (http://www.ogc.gov.uk/index.asp) and itSMF (http://www.itil-itsm-world.com).
Take a look at ITIL - especially if you're an admin: It's worth it!
Enjoy,
ix
In my view, the basic goals of CM are: (a) know what you shipped, (b) know when you shipped it, (c) deliver releases on time as predicted, (d) have product functionality decisions actually under the control of product management, and (e) drive product functionality from actual customer requirements.
Set out like that, it seems blatantly obvious that that's the way things should be, but when you start trying to make things work that way you'll find that the required changes to working practices are controversial.
Lots of developers will hate you. Developers like to be able to go fix any problem they happen to notice without telling anyone, and they hate documenting things. They don't test adequately enough to even ensure that their fixes work, far less prevent regressions. (Yes, that's gross generalizing and unfair to many, but I'm also a developer.)
The QA and documentation teams will love you, for exactly the same reasons.
If the current situation is a mess, which it probably is if they're desperate enough to offer the job to someone with no experience, it'll take at least a year to straighten it out.
In fact, before accepting the position, make sure it isn't a Poison Chalice Project.
Expect massive political battles, flamewars, perhaps even sabotage by primadonna developers.
Make friends with other clueful people who've worked on CM and process improvements. Run ideas past them, discuss problems with them, and so on. They don't necessarily have to be people at the same company.
Reading suggestions I haven't seen anyone else mention yet: "AntiPatterns",
"The Rational Unified Process".
Also, bear in mind that if you manage to fix things, and development suddenly start shipping reasonably bug-free releases on time, you are unlikely to get any of the credit. The prima donna programmers and project managers will get the glory.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I'm now at my 3rd CM position. I feel that my non-technical background actually provides me which a great ability to think big-picture and long term.
:)
:)
- You are entering the world of the arcane. Many engineers and sysadmins keep the CM system at arms length, and don't really have a good concept on how it works. Most Managers have trouble understanding what CM Engineering is ('I double-click setup.exe and the product just installs. Can you do that?').
- Because of the arcane nature of your position, promote your accomplishments. Make sure that people know what you do and that you are appreciated.
- Your coworkers probably have alot of great ideas. Talk to them and see how they can help you to help them
- Clean stuff up and keep it organized. Many developers, sysadmins and managers probably don't even realize that disorganization really interferes with getting even the basic stuff done more efficiently.
- Work smarter not harder. Focus on creating procedures that are understandable by your coworkers and which can be easily replicated for other tasks. Write scripts and programs to use those procedures.
- Document your procedures (and scripts) really well. You might want to put some of the debate and your reasoning for doing things the way you did them so that people will understand why you did things that way.
- If the system is very complex, then something is probably wrong. Super complex systems are usually unnecessary, even if you have many products. If you have many products, chances are they have alot in common with one another. If you utilize those common features, organize the overall systems and keep the long term goals in mind, you can probably simplify things by a great amount.
- You will end up loving or hating the person who came before you. Either way, you will probably need to get inside their head, even if they documented the systems well.
- Likewise, the engineers will probably end up loving or hating you. If the engineers want want to get inside your head to know what the hell you were thinking, something is probably wrong.
- Personality matters. Your coworkers will defer to you for many tasks, and you will probably end up managing people in some way.
- The CM world can be very academic and uses too much industry jargon. Learn how to explain the system in normal human terms. Also, you will probably be at the center of alot of spirited interdepartmental debate, so will really help if you can explain your position in words that everyone can understand. Around here, many people have remodeled their house, have a garden or build things. "Pretend we're building a house. The foundation comes first, then the walls, plumbing and electrical systems. After those are in place, the interior decorators can do their thing." "Weed in the winter, then mulch, then plant. Oh yeah, and you need to water and weed once in a while."
Oh, at my last CM position, I cleaned stuff up and automated so many tasks that I ended up scripting myself out of a position when the layoffs came (There was still a ton of OTHER work to do, but well... go figure). Be careful about that
"Can of worms? The can is open... the worms are everywhere."