Why I Use TFS 2010

Team Foundation Server 2010 is not a muscle car.

Developers are a temperamental and combative in nature.  Many business people justifiably treat us like the troll under the bridge due to our gruff and matter-of-fact way of addressing controversy.  Some of us even look and smell as bad as these mythical creatures.  Nothing inspires more troll like behavior than developers debating which technology or tools are superior.  Another chapter in this ongoing discussion came from Derek Hammer and his blog “TFS is destroying your Development Capacity.”  This article is well footnoted, inflammatory, and filled with plenty of reasons not to use Microsoft’s Team Foundation Server 2010 or TFS for short.  I want to take time to answer some of his criticisms and explain why I am sticking with TFS for my business. 

Hammer’s criticisms are fairly clear:

1)      TFS version control is frustrating to use.
2)      Bug Tracking is hard to use.
3)      TFS is not flexibile enough for Agile project management.
4)      The build system is clunky.
5)      Finally, the vertical integration of the product makes it impossible to use best practice tools.

Let us start from the beginning, if you grew up in the business with Visual Source Safe and Visual Source Safe 2005, you will understand that TFS is a quantum leap forward.  Code can be exclusively checked out to one developer or several developers can work on the same code and merge it together.  Also the ability to branch and merge code is clean and easy to understand.  This makes it possible to have code in development, staging and production environments existing in source control.  This is a huge help if a problem crops up in production and it cannot be reproduced in the other environments.  The label and history functions make things easy to track and using project settings forces developers to comment check-ins and associate check-ins with work items. 

Hammer does have some legitimate gripes.  TFS forces you to be connected to the server via your “workspace.”  This is a bit of a pain for people who think source controls consists of copying and pasting folders.  Fortunately, this criticism will soon be moot because the next version of TFS will allow you to work locally and then connect to the server to synch changes.  He also talks about a simple four window three-way merge.  Personally, I have not seen this and I did not even know it was a standard.  I would like to see an example of this.  Please leave a link in the comments. 

Next, Hammer dislikes the bug tracking system.  This was what sold me on TFS.  Work items, bugs and tasks can be entered via Visual Studio or the web site which is built into the system.  The web interface in no more difficult than SharePoint and customer service reps can easily be trained on how to fill out the information.  Finally, TFS has its own API so if you are not happy with the interface you can write your own web form or MVC application to place bugs into the system. 

Moving on to Hammer’s third criticism, TFS is not suited to Agile management.  My biggest challenge as a developer and consultant has always been having the client adopt any kind of Project Management Operations.    This is particularly true in the organization that thinks project management consists of leaning over a cubical wall and asking a developer to build a website.  Thus, TFS is a fantastic introduction to agile and its principles.  I still use a white board for the project team however; TFS helps creating excel reports for management a breeze.  Also, I create custom reports all the time to view specialized data.  When I was at a client, I act as scrum master entering data into the system and leading the project.  I also spend a lot of time training others on how to use TFS to get the most out of the system.  For a mature Agile teams, TFS may seem like an impediment but for companies just getting started, it is the perfect set of training wheels.

Next, Hammer talks about how the build engine is clunky.  Without any reservations, I can agree with his criticism.  In my nearly two years working with TFS, the build system has frustrated me the most.  Often, I simply rely on Microsoft Visual Studio’s publish tool, web.config transformations and FileZila to get work done.  Fortunately, I see this changing.  The Chicago ALM group had a great meeting on Sept 14^th 2011 illustrating how to customize the build process and I look forward to more people coming forward and sharing their knowledge of the subject.  Until then, I am sticking with FileZila. 

Finally, Hammer criticizes the vertical integration of the product and how it is endemic of “The Microsoft Way.”  It has been my sad experience that most people who make decisions about technology are not technologists themselves.  Thus, they are not thinking about best practices or better ways of doing things.  To this kind of individual vertical integration is a perk and not a defect.  With TFS, they see and all in one package that is easy to install and does what is required of it.  This leaves it up to the technologists to us the tool they have been given as best they can.  If that means we write web apps for the customer service people to put bugs into the TFS system and we run reports each week and send them out as excel, so be it.

Let us compare software to automobiles for a moment, Hammer sees TFS as a clunky minivan which gets people from point “A” to point “B” with little speed or flash.  What he wants is a sport car where he can open the hood and swap out engine parts for better performance.  Talk to any Mom and they will tell you when push comes to shove they will settle for the minivan.  This is why most businesses are moving to TFS as well.   It may not be sexy and flashy but it gets the job done in a way technical and non-technical people understand; this why I am sticking with TFS.  I understand the tool.  I know that I can train other developers how to us it.  Finally, it makes sense to business people who usually pay the bills. 

As someone who used to be a troll under a bridge, I understand Hammer’s perspective.  Now as I begin my own company and transition to working with C-Level executives, I see that there is more to a technology decision that just the technology itself.