TFS Migration Or: There's Still No Silver Bullet

Recently my company started a migration project to move all of our internals tools over to Microsoft Team Foundation Server (TFS). If you're not familiar with TFS, Microsoft bills it as an Application Lifecycle Management (ALM) suite which handles everything from source code control, to bug tracking, to project planning.

Currently, tools and processes vary across teams. My company has been the result of mergers, of growth and shrinkage, and the toolset reflects this. Many tools are shared across teams, but there are differences. For example some teams use HP's QualityCenter for bug tracking, while others use Bugzilla, while my group uses an in-house bug tracking system written years ago and no longer actively maintained.

The promise of TFS is to standardize our processes and tools across all teams and to make life simpler by having a single toolset that can track any given item of work from inception through completion and after.

TFS has been the pet project of one of my fellow development manager's within the organization. In fact, he was my boss when I first joined the company. He's the one that has pushed hard for TFS, including bringing a consulting agency onsite to evaluate our tools and see how TFS might help us (funded by Microsoft it should be noted), putting together the proposal for the company’s operating committee, and serving as evangelist for the tools.

He’s also made repeated (and somewhat forced) attempts to show how TFS will revolutionize our lives.

Don’t get me wrong, some aspects of TFS seem intriguing. It has some very powerful features. One of the most interesting is its ability to recreate the environment within which a bug occurred, so that, say a tester encounters a bug while testing, he can save the state of the servers on which it occurred, and the developer can at some point later, actually spin that exact environment back up and step through the code as if it was executing at that moment. That’s pretty cool.

As a source control system, TFS seems to be fairly decent. I think it misses the boat in its reliance on a centralized repository (versus the more recent developments in distributed revision control systems), but its notion of discrete changesets, and its management of branches seems to be significantly better than CVS.

But at its core, it’s a Microsoft product. And that has some very serious implications. Joel Spolsky’s keynote address at the recent Stack Overflow conference was about the dynamic between keeping things simple and giving people the power and flexibility they need to do what they want. He came down to the conclusion that the problem isn’t necessarily in giving people too many choices, it’s in giving them choices that are meaningful to them.

To me, the TFS interface is typical Microsoft. Incredibly powerful and flexible, but for you base cases, the stuff that you want to be able to do intuitively and easily, it makes something that should be a click or two into a 10-step process, that is needlessly complex.

One example is creating a new task in TFS. So, you have a story in the system and want to break it down into tasks. You’d think that’d be simple. So, you click ‘Create Link’, then you are taken to another menu, where you select the ‘Link type’, of which ‘Task’ is one choice. Then you make a selection of ‘affected by’, ‘affects’, etc.

I don’t know about you, but to me this should be a one click operation. All the abstraction and flexibility it just annoying for 95% of the time I’m using it.

But I suspect TFS will be an improvement on what we have currently. The thing is, I don’t think it will make that much of a difference. A good toolset (and one can argue over whether TFS is a “good” toolset) is all well and good. But the real problems in software engineering are not the tools, but how they're used. And without a significant investment into making our processes simpler, having people who apply those processes with critical thought and not blindly following some set number of steps, is what makes things more efficient.

And even if TFS is the greatest toolset is the world, go back to Fred Brooks' seminal ‘No Silver Bullet’ article. Such systems only address the accidental complexity of software engineering, not the inherent complexity. As such, they cannot result in order of magnitude increases in productivity.

To me, the money which has been spent on TFS (which is not insignificant) would have been far better spent in bringing in experts to look at our processes, our team organization, at reducing the bureaucratic processes that waste so much money and time, not some shiny new toy.