How Configuration Management Is Changing: An Interview with Joe Townsend


JV: Do you think CM fits more in with these mission-critical builds and modern-day what private sector offers? Is it more inclined to fit in with that world, as opposed to somebody who's building apps on the iPad who wouldn't know how to even respond with an audit.

JT: I think it fits better in the defense industry, because they're more used to it. I've been around folks in the defense industry and the aerospace side. They get configuration management. They understand its importance from beginning to end. It is very structured. Everything is very structured. You got to follow step a, b, c, d over and over.

When you're working in the private sector, sometimes the haphazardness of it is, you can't have the structure. From a configuration management process, it's really difficult to not have structure, because that's what we are. What makes us good at being configuration managers is that ability to containerize it and to hold things, and to control them. When you go to a private sector, you have to let some of that go.

You could still do it, but it's got to be below the radar. You have to do it where you're doing it, and the developers don't know it. When something happens, you can then provide that safety net that, "Oh you know what guys, I've been trying this. I know what's new. I know what was in that build, and here it is. What happened four builds ago, what happened three months ago, where were we at? Just one second, I can tell you." It's more behind the scenes, kind of the best boy grip, something like that. You're doing all the work and no one ever sees, or no one ever notices until the credits.

JV: You could do the whole job without actually ever explaining the configurable item, or having to explain to someone the terms.

JT: Absolutely. I never talk about those things. That's the good thing about how I grew up in the CM, is I can talk about those things. I can talk theory all day. At the end of the day, when it comes time to hit the road, that theory is not very valuable to a private sector right now, and agile isn't either. Yes there is "Did you get that continuous integration server set up? We had ten builds today. Yeah, which ones were successful?" That kind of stuff. They're not going to want to know that you can go in and give them a status update on the current issues. They can do that with a spreadsheet or a tool from Bugzilla.

JV: What do you see CM being in the next couple of years?

JT: I think it's going to continue to grow. I think there's going to be a continual need for it. Again, it's becoming more functional. It's becoming more, "You're going to be the build manager. You're going to be the release manager." You're not going to be called a configuration manager anymore. You're that person who does configuration management things, but you'll be the build manager, the integrator, the employer. I think as long as defense contracts and government control, they have the standard that they have, that'll always be in place.

I'm afraid that as these people, as these project go and the age starts getting to these folks, that I think the functional folks are going out in the end. I know there are some government agencies looking at agile. That's an oxymoron, government projects as being quick and lean and doing things in any kind of fashion or form other than the waterfall. It's starting to penetrate the government side.

When that happens, I think the CM empire is going to fall to the functional side. They're going to see the importance of it, and how our job helps. I think they'll interact well together if you have someone who's willing to step back from the theory and put that into practice, put the CM principles in practice. You can still hold true the four pillars of CM, but you can definitely change enough to where you become more beneficial to the team. That's always going to be the case. We're a support group. We're not there running everything. We're there to support the developers, support the QA, QC, and to make sure that things are being done right.

JV: That safety net that make sures everything's repeatable and nothing breaks or anything like that. Do you still see government adapting agile or is it just all talk, hearsay?

JT: I think it will increase. As the new developers grow up and as the kids come out of college, they're going to want to work on these new, exciting teams. They're not going to want to do waterfall. They're going to want an agile. To me, agile just works so much better, because you get the involvement early on in the process. In the development process, you don't wait 'til you did your requirements, you've done your design, you did your development. You send it to QA, the customer finally sees it in UAT, and they don't like it. That can't be sustained, not with the way the apps are needed, their quickness. As you can see, I think that the Flappy Bird guy is a good example. He had something there that really was a simple application. It blew up.

JV: Flappy Bird, yes.

JT: It really did. It blew up. If that was a team developing that rather than one person, there would have to be fifteen different versions of that for different languages, for different cultures. It's a simple game, but I think it illustrates that. Today, the way apps are being developed, that app didn't probably take very long. If he would have wanted to stick with it and say, "Hey, I want to blow this thing up and do it in Chinese and Russian and Vietnamese and Japanese and French and German, I'm going to make tools more for their environments. “

You can't do that during  waterfall. You have to do everything quick, get everything done. I know Flappy Bird, you don't really think of as being language-specific, but you know what I'm saying? If an app needs to be changed quickly, you can't do waterfall. You're going to have to do agile and get the people involved early. That's the duty of agile. It gets the tester, it gets the business user, everyone involved early so you don't wait for the last minute to find out that, wow, this is not really what I wanted.

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 01
Oct 15
Nov 05
Nov 14