|
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.
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 14th 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.