Around ten years ago I was working for a pretty backwards IT department. We wrote and maintained an internally deployed call center application in Foxpro. We didn't use any source control. The shared libraries for the multiple, customer specific versions of the application were on a shared network drive. When you ran the build script, a new version of the application was instantly put on another shared drive and almost as quickly wound up on a phone agent's desktop.
Over a weekend, one of the lead developers decided that we should have some sort of source control. Rather than use any of the many mature (and free) versions of source control, he decided to write his own–in Foxpro of course. His version of source control simply made everything on the shared library drive read only. You then ran his program (named "vc") on some component and it would log that you had it checked out. When you checked it in, it made the shared version writable, copied your version over it, and logged that you checked it in. That's it. There was no tracking of revisions, no versioning, not much of anything really.
When the department finally decided that this solution wasn't good enough (a couple of years later) several people recommended using CVS. However, now that they were intent on improving their process, the management felt that CVS just wasn't good enough for our unique needs. Someone from outside the company sold them on using ClearCase at several thousand dollars per developer. Of course, we didn't use or need any of the supposed features of the product. In my eyes, ClearCase was/is no better than CVS. From the management point of view it was better because we theoretically got support, it better fit our "complicated" development process, and someone outside the company told them it was better.
New Company, Same Issues
A couple of jobs and many years later I found myself in a much bigger, more mature IT department. The new problem wasn't source control, it was the process. We were using a painful waterfall development process. The management over the IT organization decided we should switch to a more agile process.
Most of the developers I worked with viewed this as a very positive change. Up to this point, all project management occurred in Microsoft Project and Word files. Now that we were changing things up, we could probably use a different set of planning tools. One of my co-workers (Matt Ray) had used XPlanner at a previous job and felt it was "good enough." Somewhere in the decision making process it was decided we'd have Rally come in and teach us how to be more agile. We were also going to use their project management tool to organize our tasks. Being well outside the decision making process on this, I'm not exactly sure how much money all of this cost us, but I suspect it was quite a bit. Was Rally's mentoring valuable? I think that it was, but I think that its primary value was that it is always easier to listen to someone from outside of your own company rather than your own people. Is Rally's tool better than XPlanner? I think it is a better overall tool, but it doesn't really do anything significantly better. XPlanner really is good enough for what we needed in my opinion.
The Tools Aren't the Thing
I'm now at another job in a relatively immature IT department. We've started using an agile development process and are using XPlanner to plan our stories and tasks for each iteration. A couple of days ago, during iteration planning, one of the developers was wondering if Rally's product had a feature they felt was missing from XPlanner. In this particular case, it didn't, but it made me think about peoples' love of tools.
It never seems to fail–an IT organization decides that they're doing something wrong and the solution is to pay someone from outside the company to tell them what expensive product will fix it. Usually these outsiders tell you what the more competent people in your organization already know. However, it gives the upper management great peace of mind to have someone that makes a living telling people how to do things give them the answer to their problems. I can almost understand this but it still baffles me that, if you believe you've hired good people, you aren't listening to them. The much stranger thing is that so many people are willing to go from using a bad solution to shelling out big money for a tool with a set of features and support options they'll never use. They're convinced that one of the major problems with their process isn't the process itself–it's the tools. The same thing happens with people on a personal level. I could get buff if I had a gym membership and I could get organized if I had a PDA. This is the easy "fix." Just buy a silver bullet to make the problem go away. People and organizations need to learn that they need to address the root of the problem first, usually with free tools that are "good enough" (if not outright better than their commercial counterparts). Once you do that, you're free to buy some tools to eek out a few extra points of efficiency if you still feel the need. But, most of what you need to do is purely behavioral and largely free to start solving–at least in terms of money.
I just saw another tool named ScrumWorks that apparently recently became free to registered users. If XPlanner doesn't do it for you, you might give this tool a whirl. I personally haven't looked at it very much.