We’re kicking off a new format where we’ll be interviewing CM professionals from around the globe to learn what tools they love, which ones they don’t, and what would make their lives easier. This week, we sat down with Joe Townsend , configuration manager for the Indiana Public Retirement System, to learn where his loyalties lie.
Noel: What's the primary tool you're working with, and how long have you been working with it?
Joe: For version control I am using PVCS Version Manager and I have used it for about 14 years. For issue management we are using Service Now and I have used it for a little over 1 year. Our builds are run using command files and Ant scripting. We also use Oracle JDeveloper for our Oracle code builds. Our code releases are manual, we use scripts, or Weblogic for most of our deploys.
Noel: What tools do you have past experience with, and what made you switch to your current favorite?
Joe: I have used Visual Source Safe and PVCS Dimensions in the past for version control. I have used PVCS Tracker and Serena Business Manager for issue management. I switched to the current toolset through my job changing and the needs of our organization changing. I have to say this about PVCS Version Manager - it is the best tool for non-distributed teams that I have seen in the market. Git, Subversion and Mercurial can’t even come close to it in terms of setup, usability and functionality.
I can have a company setup and running in 10 minutes using Version Manager and have the developers trained in another 15 minutes. It has command line capability and a great GUI to go along with it.
Noel: What allows a tool to be scalable or adaptable to other organizations/companies?
Joe: The main thing any tool should be able to do is be easy to use. It has to be configurable to meet the needs of the organization and you need an expert setting it up. I have seen many times where a company will try to go the cheap route and not pay a tool administrator initially only to have to bring them in 6 months later and pay someone to fix the mess created. The problem with that is the tool has a reputation based on incompetence of the implementation rather than what it is capable of doing.
Scalability also has a lot to do with where your team is located. If you have a dispersed team using a centralized approach its not going to be easy. Keep that in mind when buying a toolset.
Noel: What do CM tools need to be equipped with to be able to be implemented on an agile project?
Joe: A good tool administrator who understands the agile methodology and a understanding of CM concepts. From the tool perspective it must be easy to use, be quick in its actions and be easily configured. In agile things are happening at a faster pace than traditional development so the tool itself must be “agile enough” to support a process that is changing rapidly. The last thing an agile team can have is being slowed down by a tool that is cumbersome and hard to use.
Noel: What future capabilities do CM tools perhaps not have today, but would be nice to have in the future?
Joe: The biggest complaint I have today is “real” integration between CM tools and the IDE’s developers operate in. In the past the larger companies have purchased other tool companies looking for technology or a piece of