Team Foundation Server backlash

There has recently been a backlash against Microsoft’s Team Foundation Server.  Team Foundation Server attempts to be a one stop shop for the following:

• Source Control
• Task/Bug management
• Build management
• Test management

The consensus seems to be that it doesn’t do any of these things particularly well. 

With regards to source control, speed is everything.  Especially when you have a geographically distributed team.  TFS fails here because it is optimized for local networks but crawls miserably over an Internet connection.  Also equally important is accessibility.  TFS requires a Team Edition of Visual Studio and Team Foundation Client Access License. Without a free version to help begin adoption rates, it is difficult to justify the cost.  Additionally, there is no option for anonymous source access using TFS, making it an unlikely choice for open source projects.  I know of many open source projects that chose Google Code over CodePlex for this reason alone.

One aspect of TFS that many users rave about is the Task/Bug Management.  Being able to tie changesets to tasks on a project plan can be a huge boost for a project manager/development lead.  However, it can be overkill for small teams.  My experience with the Work Item tracking is that it becomes cumbersome within small teams and the Work Items quickly become meaningless as the project reaches a rhythmic development process.  This can be very dangerous and lead to a false perception of the project ‘s status if Work Item tracking is the only visible metric of the project’s progress to the project’s sponsors.

With regards to Build Management, TFS lacks out of the box support for Continuous Integration.  This is a major flaw because TFS fails to accommodate many organizations that have thrown their weight behind CI.  Also many users have an existing base of nAnt scripts that they have been using for builds.  Without no integration or easy migration options, TFS becomes difficult to integrate into such environments.  I know of someone who actually has his MSBuild scripts internally execute his nAnt scripts because his organization was migrating to TFS and rewriting all of the existing nAnt scripts in MSBuild simply wasn’t an option.

Finally, with Test Management, TFS is still very unproven.  Most QA groups have a lot of difficulty justifying even basic automated tools and typically use either a suite of small scale testing tools or one large testing platform from IBM, Borland, or HP.  If TFS included basic integration with some of these existing testing platforms, it would be much easier to justify the cost of the product.

My opinion is that if you are modernizing a large development group or if you just migrated over to Microsoft .NET from another platform, Team Foundation Server can be very attractive.  However, it is very difficult to integrate into existing teams that already have a working system in place because it generally falls short in one or more of the four aforementioned categories.