Don't Become Hostage to Development Process Suites

Our organization never bought into any one software suite, and as we understood our own software process needs, we moved far away from the requirement that all of our tools should interface with each other, or that they all be purchased from a single company. In this article, I will discuss why we don't work with any particular software suite, and why I think that tying a development organization to any one integrated suite may be a mistake.

Those Simpler Days of Lore

A long long time ago, before I'd heard of CM, SCM, CMM, pattern languages, and best practices, I was a buildmeister. Along with running the project build scripts, I also integrated our version control, build, defect tracking and release process tools with our home grown scripts. Everything was run in a command shell on MS-DOS and SunOS. When the web was first available, I created a simple CGI script to handle part of the release process. Our tools came from various vendors.

One could reasonably argue that we had a well integrated development process environment, albeit undocumented, and without the graphical interfaces we now expect from our development tools.

The Race to Create a Process Suite

About eight years ago, there were several very good version control, design, requirement management, test automation, and defect tracking tools. They all came from different venders. Most had ways to customize and interface through trigger scripts or simple command line instructions.

Then companies started buying out others, merging their process tools into development suites. At first, a few process tools came out of the same vendor. Because they were created from different places, they didn't look alike, and had a loose integration, if any. They were designed to be customized, so either you used their scripts to link defects to versions, or you did it yourself.

Then, some companies came out with all inclusive tools. They're designed for enterprises to standardize on, and come at a very high price. You need the entire tool suite for any part to work.

Finally, a couple of venders started publishing the best practices for doing software development, and modifying their tools to work according to those practices. On the surface this looks like a really good step forward, as long as you can still choose which tools you want to work with.

I suspect that these all inclusive tools are based on work at large clients. Sort of, it worked for them, so it probably will work for anyone.

Problems I've Seen With Process Suites

So, what's wrong with buying all your software process tools from one vender? Nothing, if you've got the money or lack the resources to tie your own tools together. I think that's a big, "If." I'm thinking of startups and small established companies whom have low budgets for their software development tools, as opposed to the large clients who grab the attention of the CM tool vendors.

I'll start with the fully integrated process tools which follow some universal set of best development practices. My experience is that these tools are very expensive, even when bought as a suite. I also find that you need two or three of the tools, and rarely touch the other three. Often the integration doesn't work as advertised, and you find most of your administration efforts in getting each tool to play with each other.

The biggest gotcha is that they tend to be indivisible. That is, if you want to upgrade one, you've got to upgrade the whole lot. Because these tools often have common code, you can't run different versions on the same computer. Now legally, you can buy a design tool, and never have to pay for maintenance or upgrade it. If the version you bought three years ago still works for you, why upgrade? On the other hand, you want to maintain and get constant support for the issue tracking software of the same suite. But, you can't upgrade it without also upgrading the design tool. So you end up paying for the support and new features of the design tool, even though you don't need them.

Another problem I see with the all inclusive tools is that when your development process matures, the tool's very structured process may no longer work for you, or you may continue to like one part of the tool, say the issue tracking, but find that you need a different approach to test automation or version control. Must I continue on this line of thought? You bought it all in one tool; you've got to continue working with it.

I like companies who sell lightweight tools, which don't do it all, but do what they do well, and are relatively inexpensive. They should allow me to plug and play with other CM and development tools.

A Little Education Goes A Long Way

I worked for a few small companies with limited development budgets. We bought a version control tool, and bent it to our needs. We hated our issue tracking tool, needed an outside consultant just to add a new field, but we didn't have the time or money to buy another tool.

Today, I work for a corporation with a massive budget for development tools. And yet, we don't have a corporate wide standard issue tracking or version control tool. Is this for lack of a CM plan? No. It is part of a philosophy that every project decides how to organize their processes and development tools.

Still, there is only so much time and people power we want to spend on supporting development process tools. So, we don't buy a new customized suite of tools for every project.

But, we have another resource: education. I think it is fair to say that every organization can easily leverage off of what they already know about development processes. There are lots of courses available to learn how to write requirements, how to design software, how to create test plans, and so forth. Most of these courses don't tell you, use vendor product X to get it done right, unless you took that course from a vendor. Often, project managers I work with have a good idea of how they want to work.

So, we know how to manage project plans, requirements, test plans, high level designs all with pure documentation and meetings. We utilize many system design tools, low level design tools, project planning tools. In most cases, the best our money can buy. But, they aren't integrated. Next project down the road, someone finds a new tool, evaluates it, and buys it. It will fit perfectly in our development process. It doesn't have to integrate into our issue tracking tool and version control tool. It is nice when it does, but it isn't a requirement.

What about traceability between project artifacts? Believe it or not, even that is possible without automating it. I admit it isn't failsafe from a technologic view. However, the human ability of communication, in a meeting room, in the lab, through email, on the phone, goes a long way to keep all the project artifacts in sync and on track.

Perhaps the success of keeping it all in line without integrating your tools depends on your project size, non-automated development processes and corporate culture. In my own experience, I've seen projects managed successfully many times without relying on all inclusive CM process suites.

The Bottom Line

We have a few expensive tools and a few lower priced tools we keep maintaining every year. They have become part of our development culture. We have some tools we bought years ago which we still use, and have no plans to upgrade. And we have other types of tools which we are still switching to the latest from different vendors because we haven't found the perfect match.

Bottom line is, keep your options open. Don't tie yourselves to one product vendor's line of process tools. Their sales people can be very good at persuading you that they can provide all your needs. But, the real test should be your one month evaluation. Really try to use their tool with your product artifacts, and ask yourself if they are forcing a process in line with how you want to work. Rely more on your own project management knowledge to guide your CM processes.

By not tying your tools together, you keep your options open to acquiring a new one that operates more closely to the way your organization wants to work. You also allow yourselves to keep using that tool you bought some years back without paying year after year for new features you don't want.