How Configuration Management Is Changing: An Interview with Joe Townsend

JV: I just wonder, we now have medical apps, apps that are really sensitive for life. Do you think you might need some of that safety net of CM to make sure that these things are built correctly. Apps are rapidly built, but then as we're making more mission-critical apps, where is that safety net?

JT: If you go that route, honestly, you're talking about life or death for someone. I don't know how much agile would be suitable for that. You want to make sure it works. You can't test it in the field. I think it would be even more important to have configuration management there to make sure you know what you're releasing, can repeat it, and you can go back should something go wrong. If someone dies on the operating table because an application crashes in the middle, that's going to be very important to see what happened. There's going to be a lot of lawyers interested as well as to what happened and why this application crashed in the middle.

JV: I can imagine that, yes.

JT: Again there, the safety net of configuration management becomes even more important. Depending on the app, what it's going to be used for, I think that's the biggest boost for CM is the fact that no one else can in the field can give you that safety net, can give you that way of protecting things the way configuration management can.

I've seen applications, very simple ones, where developers have tried to use what I call poor man's CM, where they just make copies of folders. It gets to a point where they don't know what's happened. They don't know what they released, or what they've done. CM gives you that ability to say, "Hey, you know what? I know what went on that day. Here it is. Here's the release. Here's what was in it. Here's the executable. Here's the code behind that executable."

JV: All right. Well, we're coming close to the end here. It's been a really good talk, chatting about this. Any final thoughts you want to leave to readers and listeners?

JT: I think the main thing about configuration management is as the field has—one of the things why we don't have a bigger seat at the table is the fact that I think there's a schism in CM between hardware and software configuration managers. They, really, you can't apply hardware configuration management principles to software. One of the things I saw the other day, someone saying, "Configuration item has fit form. Will you tell me what the fit and form of a piece of code is?" What does that mean?

JV: Yeah, what does it mean to anyone who doesn't know those terms?

JT: Yeah, I was thinking the whole time, it's said in there that in this standard, the fit and form of the product. Just like in hardware, yes, many parts make up a larger part. Same thing in software. A knob is a knob. A dial is a dial. A altimeter is an altimeter. The software behind that altimeter is very different than the actual piece itself. We have to get past that. That's the one argument that I see over and over in forums and groups is, people want to apply same principles to hardware that you do software.

JV: It's not going to fly.

JT: It's not going to fly. It's not going to work. We have to understand, as configuration managers, that's different. To explain that to folks here who are not used to that, I've done it before at a conference. It's a lot of heads nodding, but at the end, I don't think they really understood what I was talking about and didn't really agree what I said. I got to keep saying it. We got to quit looking at these things the same. Software doesn't have fit and form. It's all over the place. We have to just control it as best as we can.

JT: Right. All right, well thank you Joe so much for taking time out and talking. People can check us your stories that you write for us on Techwell and on CMCrossroads for more information. Thank you so much, Joe.

JV: Thank you, sir.

JT: All right.

Joe Townsend has been working in the configuration management field for fifteen years. He has worked for CNA Life Insurance, RCA, Boeing, UPS, and INPRS. Joe has primarily worked with Serena tools, including PVCS Version Manager, Tracker, SBM, Dimensions, and Subversion is also an administrator for WebFocus, Service Now, and supports Eclipse users. He is responsible for building all of the applications at his current location, which includes a desktop and web-based client.

User Comments

I've been doing CM-ish stuff since the 80's, starting with building our own primitive version control system based on DEC-10 DCL primitives (where when saved a file, you'd get a new copy with a version number attached to the name!). I learned a lot about process--QA and CM--from Boeing as well in those days; we developed compilers for use in building B-1s and B-2s. It was an invaluable baseline.

So now I'm working in a small start-up, managing QA and managing/implementing CM. I set up our CI, established our SVN and now git policies, Bugzilla workflow, and manage releases for the server-side stuff.

One huge benefit to the developers that wasn't brought up in the article is that our tools and policies enable crazy levels of parallel development, via branching and merging. Which they appreciate--both that it can be done, and it's relatively painless. They also like that the resultant patchwork releases WORK.

Also, the guys working on mobile apps pretty much manage their git repos and test/release builds. They're quite good at it, and very disciplined. I think the github generation will not question the need of CM; in fact, developers will be practitioners; many already are.

About the author

Jonathan Vanian

Jonathan Vanian is an online editor who edits, writes, interviews, and helps turn the many cranks at StickyMinds, TechWell, AgileConnection, and CMCrossroads. He has worked for newspapers, websites, and a magazine, and is not as scared of the demise of the written word as others may appear to be. Software and high technology never cease to amaze him.