JV: More of a hindrance than a help.
JT: Absolutely. Things are supposed to get better as time progresses, but I think with the CM tool market, things weren't progressing fast enough for the development market. Of course, the rise of agile at that same time and lean concepts, it was just coming to a point where you were spending more time dealing with the tool than you were dealing with your trade, from a developer perspective. As a CM practitioner, we didn't fail, but the vendor side did. You had the advent of Subversion, yet there were other tools that were simpler. Just version management at first. These developers flocked to it because you couldn't beat the price. You get a tool like ClearCase, ClearQuest, everything else, Dimensions. You're looking at a substantial investment, and these teams weren't getting the bang for a buck; just weren't getting what was advertised.
JT: Now, that's changing with these teams that are working with Subversions, integrating them into tools. I'm actually working on a project now that's integrated. It's got Subversion integrated into J developer, Oracle development tool.
JV: Oh, wow.
JT: It's seamless. It really does what it needs to do. It's simple. The developers are in their IDE. They call us. Again, you can't beat it when it's free.
JV: One tool can speak to the other tool. They can correspond with each other easier than before. Whereas before, the promise here is the big package you're getting, but wasn't really like that.
JT: Nothing really worked well together that time. Now with the open source and the community just thriving- they're writing the integrations between Codezilla and Subversion and Git and everything. They're writing- basically, they're writing the plug-insurance for the ALM to make an ALM solution, and it's all free. That's been huge, and it's going to continue, I think.
As you can see from Serena just recently being sold again to a private partner. IBM offering Rational to obtain licenses for free. They're seeing that they can't compete in this market because they didn't have what the developers needed. I think we're getting to see a real renaissance in the CM world as far as tools are concerned, were it's going to get much more robust than we could have ever had with the big vendors.
JV: Got you. Now we know that you know the tools are modernized. What about the role of the CM professional themselves? How are they fitting within this larger IT?
JT: Really, there's two types of CM professionals, maybe three if there's people that are field managers. it's hard to say, because we're going from being configuration managers to being more functional in nature, like release managers or build managers, deployment managers, or the change managers, or avocation changes. You've got a functional side versus the four pillars of configuration identification: control, audit, and status accounting. That still exists heavily in the defense industry, but in the private sector, it's becoming more functional from the configuration manager's side.
Me, I'm a jack-of-all-trades. I do everything. I do build, release. I take care of the tools, support, help desk. I do everything from a CM perspective. Depending on the size of the company and the size of the effort, all you ever may do in your configuration management career is do builds. You may be the release manager for ten, fifteen years. That's all you do, the release management side of the configuration management.
JV: The roles sort of been broken up into several parts. One of those several parts, that might be a person's job for maybe their whole career, as opposed to overseeing the whole process.
JT: Absolutely. Now, there's that side. Then, there's what I would call a true configuration manager, who's taking care of the process side. That's more prevalent in the defense industry, government, and larger efforts where you may never do a build, you may never do a release, you may have nothing to do with the functional side, but definitely handle the process side of holding the cabs, making sure that the processes are being followed, and writing the configuration management plans. The overwriting of the individuals for the projects. That may be your job all the time, it's just taking care of that clerical stuff.
JV: Right. Yeah, that seems like that role is better suited for, like you were saying, the projects that are huge. There might not ever be a release. When you think of the apps that are constantly being developed now with such a fast-paced development cycle, how do you see the role of CM fitting in with today’s private sector? The way apps are getting created nowadays?
JT: Well, with agile and lean concepts, you can have a two-hour change control board. You've got fifteen-minute sprints, and if you're invited, in that fifteen minutes, you may have thirty seconds to have your voice heard. I still think that developers and agile has to understand importance of configuration management, but you're not going to be able use the traditional things that you may be used to. If you came from a defense industry to someone who's writing apps for iPads, I think you'd be dreaming to think you're going to come in there and have three-hour configuration control board meetings. It's not going to happen.
I think that's one of the problems of our industry is people see, if you're not doing all of it, if you're not being a purist, then you're not doing configuration management. I beg to differ. I think you're going to have to get rid of the wasteful side of CM.
Just for example, you can talk about a configuration item. I've seen conversations going for months about just configuration items. No one's going to have time for that in a lean environment or a Scrum. You're not going to go sit there and say, "I didn't know what the CIs are." They're not going to understand what you're talking about. If you start talking about configuration control, “I need to do a status audit or status accounting,” they're going to think you've lost your mind. They would say, "What are you talking about? We need you to do the version management side of it. We need to set up continuous integration. We need bills. We need these things. We need thee functional things. I have no idea what you're talking about when you say configuration status accounting."
JV: Yeah, it's just a term to them, to some people.
JT: Bob Aiello once said that to me that if you try to say those terms where he sat up in Wall Street, they're going to run you out of there. They don't know what you're talking about. They don't want to speak about it. They need you to do something. Looking at it from a functional standpoint, what can we do? What can we cut out? What can we not have to do to make things go faster? That's the whole purpose of configuration management—to help the team to make it work better, cheaper, faster.
JV: Right. The irony is that some people just don't quite understand it, so then it becomes more of a hindrance than something that's beneficial. How does these two trains of thoughts fit in, then? How can agile and CM coexist when you got people who don't understand and you got the CM person who has all this expertise?
JT: Even though they may not understand it, you have to take care of that side. You have to the base lining of the code. You have to make sure that things are repeatable, that everything is working correctly from the configuration management side. They just may not realize it. It's not a thing where- that's the thing about configuration managers, they don't always do configuration management tasks. It's usually done by the developer and others; the QA side, the quality control. You may not actually do the actual task, you just got to make sure they're being done. More falls on you as far as making sure that things are being done above board. Rather than trying to sit there and talk theory with folks who just want code.
JT: That's what it all boils down to. You have to make CM work where; you have to make it happen. That's a tall order. I think it's still possible. You just can't stick to the traditional ways and expect folks nowadays to understand that, or even want to go along with it. You just have to make them do it without realizing, basically, is what I'm saying.
JV: What are some ways that someone could go about doing that, doing what you just said? What are some ways that someone can convince someone that this needs to get done?
JT: The biggest side is going to be the version management side. Doing the code check-ins, making sure that your baseline, your code, that when the build's done, that you a, know what's in the build. That's the configuration status accounting or the audit that you can do. You can make sure that the build reputable. I actually do that now where I'm at. We do a build off of a branch, and then we integrate that code into the trunk. I do a confirmation build to make sure everything's the same. We can compare that to your file, and it works perfectly. If you said to do that in a traditional setting, there's no way on earth I think you can get that done where there would be that trust factor.
I think that's a big part. You need the trust factor with your developers. They know how to work with you. They know what you require. I think that's the big word here, it's the trust. You have to trust your developer. Your developers have to trust that what you're doing is adding value, making things easier, and giving them that safety net. Developers, again, every time I'm doing desktop support, they're not all hackers, but they hack things up. That's the nature of their business. That's what they do. You have to give that trust back to build where you can do things behind the scenes and you give them that safety net. They all believe that, eventually. Everywhere I've been, they needed that safety from configuration management, that safety that we provide.