How Configuration Management Is Changing: An Interview with Joe Townsend


Joe Townsend has been working in the configuration management field for fifteen years and is a regular contributor to CMCrossroads. In this interview, Joe discusses how configuration management has changed over the years, the trouble with tools, and trends in IT.


Joe Townsend has been working in the configuration management field for fifteen years and is a regular contributor to CMCrossroads. In this interview, Joe discusses how configuration management has changed over the years, the trouble with tools, and trends in IT.

Jonathan Vanian: Okay, hello. I'm here with Joe Townsend. Joe, you're a regular face around our parts, our family of publications, so nice to have you talking with us today. Can you explain a little bit about your career so far to readers and listeners who might not be aware?

Joe Townsend: Thank you Jonathan. A pleasure, of course.

JV: Definitely.

JT: My career started back in 1998 in configuration management. That time, I was one of the few people that actually got to choose configuration management. It usually fell upon the worst developer. At least that's what I found when I went through my training classes, that someone would say on Friday they told me I had to have this training class on Monday and I was now the configuration manager, so I have to learn these tools. At that time pretty much everything was tool based. People were thinking version management was configuration management. That's the first class that I went to that seemed like everyone was saying that that was pretty much configuration management. Of course, that's the largest piece of the puzzle when you look at the functional side of configuration management, is version management.

Way back then in 1998 it was just in its infancy as far the getting away from command lining and going to more of a GUI interface, more configuration management tools. I ended up leaving the company that trained me after a year and started consulting, first at Thomson Electronics in Indianapolis and at Boeing Aerospace in Alva, Oklahoma, the C-17 program, which took me to United Postal Service on the Hub 2000 project in Louisville Kentucky, their air hub. I implemented, basically, the version management and issue management at their location.

At Boeing, they were more advanced than most companies. They were in aerospace and defense, so they were really light years ahead of most companies as far as configuration management, having an understanding of its importance. There, I just implemented a tool that seemed to be the going thing at the time. The tools were brand new, everything was fresh, everyone was excited about the possibilities of the tools.

JV: What drew you into that? Why were you attracted to that?

JT: One of the most important reasons was I could become certified in the PDC suite of tools at that time. Like anyone who's young in IT, certification means something. At that time, it fit. It really was the field itself, being able to help the developers and the control of the environments and coding. Really, it just drew me in.

JV: The organization aspects of it.

JT: Every bit. It pretty much fit me as a person because everyone who knows me knows that I'm a law-and-order kind of guy. CM at that time was pretty much the Wild West, as far as development goes. People were just everywhere and doing things, and disorganized. There's no talk of agile, there's no talk of lean, or any kind of structures. People who were coding at that time were getting ready for the Y2K bug. I was working on a COBOL shop. Of course, that was huge for us. Supposed to get everything done, get everything built, get everything ready for year 2000.

JV: Definitely. Order, control over that, especially for that storm that could have really been destructive.

JT: Yeah, the storm that wasn't.

JV: The storm that wasn't. Obviously, the nature of the world is changing over the past decade. Walk me through configuration management, how it's been changing. We've got the rise of the cloud, new technical advancements, new management styles.

JT: It's obviously changed since 1998. I think the biggest thing was the rise of the ALM tools, like PDC, Dimensions, ClearCase Suite. Those really didn't do what was advertised. At that point, even though CDS had already existed way before those tools, and it was being used, the ALM side never really took hold of it. These companies were buying each other out and buying add-ons and doing all these different things.

JV: When you say they weren't really doing what they were doing, what were they supposed to be doing?

JT: They were supposed to bring the whole build management, version management, release management, requirements management; all the whole ALM perspective into one tool. That didn't work so well. The tools either weren't truly integrated or they just were so complex that development teams couldn't really use them.


User Comments

Lonnie Brownell's picture

Enjoyed this.

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.

April 10, 2014 - 5:06pm

About the author

Upcoming Events

Oct 15
Nov 05
Nov 14
Jun 03