On Taking a Configuration Management Position? 28
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?"
Proliferation of Options (Score:5, Interesting)
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:Proliferation of Options (Score:2)
We aren't using Websphere, but we are using struts, commons-logging and log4j together in production without issue. In our case, struts is version 1.1.
As a possibility, one dev guy offers:
"So in Struts 1.0, I can see this as a potential problem if Struts wanted one version of log4j and commons-logging wanted another, but as of Struts 1.1, this really shouldn't be an issue."
YMMV, because we aren't using Websphere, so i can't speak to all that package may lump
Danger, Danger Will Robinson (Score:1)
is that a politically correct way of saying it has scope creep?
Re:Danger, Danger Will Robinson (Score:4, Interesting)
Re:Danger, Danger Will Robinson (Score:2, Insightful)
I'm currently in a similiar position that primarily involves cleaning up a relatively unmanaged collection of webservers. While your in the process of defining your position, you need to remember that once you've been around a year or two and have the mess cleaned up, the job & will probably change quite a bit.
Re:Danger, Danger Will Robinson (Score:3, Insightful)
Re:Danger, Danger Will Robinson (Score:2)
I was in the same position, I took the job. (Score:5, Informative)
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.
Been there, done that, too. (Score:1)
Yes, I did get to influence a lot of policies, and I quickly learned that Conf. Mgmt is NOT a bunch of useless administravia. There are very real benefits to such systems, if they are used properly.
Given the chance, go for it. It's a real eye-opener, and your development practices will nev
good against outsourcing (Score:4, Insightful)
Depends (Score:4, Interesting)
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.
Follow procedures (Score:3, Informative)
Temperment (Score:3, Informative)
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.
Should be OK (Score:2, Informative)
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 project
Re:Face facts (Score:1)
a view from the trenches (Score:4, Informative)
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
Another "Configuration Management" (- ITIL) (Score:2, Informative)
Take a look at ITIL - especially if you're
Avoid resistance your first time out (Score:3, Interesting)
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.
Suggestions (Score:3, Informative)
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 [antipatterns.com]",
"The Rational Unified Process [amazon.com]".
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.
Humans, simplify, procedures, document. (Score:3, Informative)
- 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
Look before you leap (Score:2)
2) Try to determine what your bosses' understanding about CM. (Ask them.) Its generally going to be viewed as an obstacle and a "cost center". If they're not on-board in terms of its importance, my guess is that it will be likely to be a detrimental move.
3) If they give you the time, get an idea of what changes you would need to make and then give them a gameplan before taking the job. If they're not onboard with
It's all obvious ... to a point (Score:2, Interesting)
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 qual
management opportunity (Score:1)
Sheesh.
I read the whole article on "What is Configuration Management?" and all I got out of it was that it "is both a management discipline and a process" -- which means that you're not a manager, and there is no process. In short, it's a buzzword role designed to sell you something. I mean sell you nothing.