
TFS is destroying your development capacity - hammerdr
http://www.derekhammer.com/2011/09/11/tfs-is-destroying-your-development-capacity.html
======
snprbob86
I have significant experience with CSV, SVN, Perforce, Source Depot
(Microsoft's internal Perforce fork), Team Foundation Server, Mercurial, and
Git. Roughly in that order of exposure.

I safely say that TFS is easily the slowest, least scriptable, most confusing,
obnoxious piece of crap software that I have ever had the displeasure of
using. The Microsoft-internal hate for TFS was astonishing, but political
pressures forced us to use "dogfood" it.

Personally, I used to keep all of my source code at Microsoft in a local
Mercurial repository (this was before Git had decent Windows support). I only
interacted with TFS when I absolutely had to.

~~~
hyperrail
How recent was your experience with TFS? It's been around for 6 years and
shipped 3 versions, that should be enough time for it to be good enough for
dogfood.

~~~
snprbob86
You'd think that right? But I left Microsoft in spring of 2010.

------
boyter
TFS truly is awful.

I am amazed that the cost is not mentioned in the article though.

Forced to use it where I work, because management wanted the reporting
capabilities that it provides and like the turnkey solution. My back of napkin
calculations came up with that for the cost of TFS we could have kept our
existing SVN/Jira/CruiseControl solution (or migrated to a hosted solution)
and hired someone at 60k a year to just write reports for the existing system,
or paid Atlassian to come up with them for us.

Add in everything mentioned in the article, the cost and that basic
functionality such as "get latest" doesn't and you have an impedance to
developer productivity.

These days I tend get the TFS code, check into mercurial/git and work that
way.

------
hyperrail
> TFVC is a centralized-server model that requires constant and active
> communication between a client (read: developer) machine and the server. If,
> for example, the network goes down for 1 hour, development grinds to a halt.
> The reason here is that TFS will mark all files as read-only on the
> filesystem until you have asked the server to check them out for you.

Perforce works the same way, causing much frustration for me whenever I have
to work with a slow and unreliable p4 server (and, despite Perforce marketing,
those exist). You can override p4 and make writable the files you want to edit
without telling the server. But when you want to check in a changeset, you
have to tell the server you edited the files, otherwise they will get left out
of the changeset. Worse yet, if you try to get too clever with your local
copy's settings, the p4 utility might overwrite your changes with a newly
checked-in version the next time you update your local copy.

When I worked at Microsoft in the early part of the last decade, we used a
Perforce fork called Source Depot. (Internet mentions of sd are rare, but here
is one: <http://stackoverflow.com/questions/491295>). I have no experience
with TFS version control, but it looks to have taken a lot of inspiration from
sd, which was a fresh breath after the previous revision control tool which
didn't even support branches.

~~~
cpeterso
Editing of local files "behind the back" of the P4 server is not that bad.
When you reconnect to the server, just ask your P4 client to "synchronize
offline changes" (in P4V, I think) or just checkout your entire clientspec and
ask your P4 client to revert unchanged files. I'm sure these operations could
be easily scripted, too.

Clearly not ideal, but workable. I'm surprised Perforce has not created
offline changelists (like git or Mercurial's Patch Queue). The feature could
probably be implemented entirely in P4 client code. Perforce has implement
server-assisted "shelving" of changelists, but I don't find that as helpful as
local branches or changelists would be.

~~~
hyperrail
> When you reconnect to the server, just ask your P4 client to "synchronize
> offline changes" (in P4V, I think)... I'm sure these operations could be
> easily scripted, too.

p4v does have a lot of added features and conveniences. Maybe I'm an old fart,
or maybe I'm just too used to sd (which didn't have an official GUI client app
when I used it) but I don't actually like to use p4v, preferring to use the p4
command-line tool. So, yes, I've gotten used to automating certain operations
via shell scripts that wrap p4.

> ... or just checkout your entire clientspec and ask your P4 client to revert
> unchanged files...

If you do that, though, the server will tell everyone else that checks out any
file that you have it opened for edit too. This can be really misleading when
they want to delete or integrate to the file. I don't like that Perforce
implicitly discourages merging branches through "who else has opened this
file" notifications, but that's how it is and I'd rather not abuse the system.

------
gokhan
I'm sure there are lots of frustrating things in daily TFS workflow but some
points in the article are quite wrong.

> TFVC is a centralized-server model that requires constant and active
> communication between a client (read: developer) machine and the server. If,
> for example, the network goes down for 1 hour, development grinds to a halt.
> The reason here is that TFS will mark all files as read-only on the file
> system until you have asked the server to check them out for you.

You can switch to offline mode, and it will sync when you're reconnecting to
the server.

> TFVC wants you to do everything inside of Visual Studio.

Yes, but it's easily extendable, and there's a power tool integrating Tortoise
like functionality to Explorer Shell. And there's always the command line
tool, here's the syntax for "add", for example:

<http://msdn.microsoft.com/en-us/library/f9yw4ea0.aspx>

    
    
      tf add itemspec [/lock:(none|checkin|checkout)] [/type:filetype] [/noprompt] [/recursive] [/login:username,[password]]
    

> In order to create this bug work item, you need to use either Team Explorer
> (through Visual Studio, most likely) or the TFS 2010 Web Interface. The
> obvious problem for the first scenario is that developers are the only ones
> likely to have Visual Studio and are only one of several groups of people
> that could log a bug

...and Excel and MS Project, by default. Web + Excel + MS Project should cover
almost all "several groups of people". And there's always this api, available
through libraries or web services.

> TFS as Agile Project Management ...

All project and work item templates are customizable, either via XML
definitions or through a power tools interface. And when you do, all the
external interfaces display your customizations without any additional work,
be it Excel or TFS Web Access or the others. And they're instantly reportable
too.

> TFS as Build System ...

It can build MSBuild scripts, Ant and Maven builds natively. Constructing
builds is always hard, MSBuild or workflow style build introduced in 2010 are
no different. Normally, any sln file governing the project can be built
without any modifications. I find gated check-ins or nightly builds quite easy
to setup, his mileage seams varying.

~~~
snprbob86
The command line tool is much nicer than the GUI, but there is still no way to
get easily machine parseable output. Unlike Git, all of the `tf` commands are
porcelain. If you want plumbing, you need to code to the COM/C# APIs.

------
secoif
I initially read this as "Team Fortress is ruining your development capacity."
and I agree. I play too many games.

~~~
vyrotek
I can write an article on this topic. I rationalize the time wasted by playing
as Engineer. I also work for a Gamification startup so I can call it
'research' :)

------
swanson
Obligatory link to git-tfs: <https://github.com/spraints/git-tfs>

------
InclinedPlane
When set up and used properly, TFS is a decent source control / bug tracking
system, especially if you use Visual Studio for day to day development.

The problems with TFS come from a few areas. First, it's easy to set it up in
some sub-optimal configuration, by putting it on insufficient hardware, for
example. There's a very real and very high cost to doing that aspect right, of
course. Second, if you're doing development with a small team and a limited
number of branches, TFS is probably overkill, and the way the tradeoffs are
balanced for TFS is probably way off from the actual tradeoffs your team
needs. Third, if writing code in the VS IDE isn't the norm then you might be
going against the TFS grain enough to cause serious pain. Fourth, if you don't
use the bug/work item tracking parts of TFS then it'll have less value to you,
obviously.

Finally, the biggest problem with TFS is the competition. People apply the
label "distributed version control systems" to Mercurial and Git but that
hides the important aspect that these systems are not _just_ capable of
decentralization but they are also extremely fully featured and highly
advanced modern VCSes. If you are deciding ab initio which VCS to use it'd be
silly to not choose Hg or Git for almost any project. They are free, there is
tons of support, they are scalable, and they are extremely good.

------
MortenK
Can't really recognize these problems. I've no problem with working offline
for example. You get the latest version from the repository, do your stuff and
check-in when your done. Conflicts are pretty easy too. I don't know this 3
pane "standard" merge view that the guy is ranting about, but the 2 pane
(local and remote version) view in TFS works just fine for me.

Bug and work items, sure, not very good. Usable, but still prefer to keep
issue tracking outside TFS.

I've only used SVN apart from TFS, and while it does the job, I mainly used it
because it's free. Really disliked the hidden .svn files cluttering up folders
though.

I've never really gotten Git or Mercurial. They seem to be for linux command-
line type of coders. But I really wouldn't know, as I haven't used them.

TFS works just fine. If you are doing MS development, it's probably the best
tool for the job.

The majority of these kinds of rants come from people who are used to
something else, then proceed to proclaim certain software "stupid", because it
does not work like their favorite choice of similar software.

A bit silly really - Use what you like, but don't engage in bouts of mud
throwing. You'll just be as much of a "factionist" as the author implicitly
claims he is not.

------
skeletonjelly
Although I agree with the overall sentiment, there are a few inaccuracies with
this article. I am not defending TFS, just correcting.

To address the point about losing connectivity, VS prompts you to "Go offline"
which removes all the readonly flags from every file and folder (I know...)
and does a folder scan like a regular basic VCC would do upon reconnection. I
haven't had a problem with this (as long as your copy is very close to the
server copy).

To address the point about multiple merges, you can select multiple conflicts
and perform bulk operations on them (accept server, accept client etc) and I'm
pretty sure automerge is one of the options.

Also yes the merging tool is horrendous. I use p4merge instead for both TFS
and git. Much easier to see what has changed and also easier to cherry pick.

~~~
hammerdr
Re: offline mode.

I've had to deal with this a few times. I make a brief mention of it in my
article but gloss over the details because I wanted to get on to more
important topics.

In general, offline mode has been a terrible experience for me. It is handled
differently in different versions of TFS. In one version (2008?), you go to
File -> Offline Mode. In another, you need to either reopen the solution and
get prompted project by project to Temporarily Work Offline or unbind TFS
manually.

In both solutions, I've had difficulty reconnecting to TFS. In a complex set
of steps that were probably "dumb" but seemed like my only options, I have
lost changes made on my local file system.

My experience may vary from others, granted. Though, after talking to some
colleagues about their experience, mine has been easy.

~~~
skeletonjelly
Fair enough. I guess the overall impression we both share of the offline
process can be summed up by the word "unintuitive".

Also funnily enough, I've just come back after lunch to find something has
killed SQL Server, which has affected TFS, forcing me to experience all the
joy that is offline mode. I'll no doubt be swearing and cursing MS in a few
minutes.

------
scott_to_s
My understanding of TFS is that the only reason it exists is to sell more SQL
Server licenses.

~~~
kevin_morrill
It was more about getting the Developer Division to be a $1 billion in revenue
department. My guess is that TFS is a drop in the bucket for SQL Server
revenue.

------
pointyhat
Agree entirely with the article.

TFS is one of those products that you feel like you should be using what with
being an ENTERPRISE, but after a couple of stand-offs with it, you feel like
you've been thoroughly well and truly raped by the vendor. This is unless you
were using VSS before at which point you are scarred for life.

I made a fair bit of cash between '03-'07 saving people from botched, painful
VSS and TFS environments. If people pay you lots of money and worship the
ground you walk on for getting rid of TFS, then it's probably a bad product.

I replaced them with a simple scripted virtual Debian/Trac/SVN appliance with
Active Directory integration via LDAP. I let them design and build their own
processes and workflows with Trac workflow. I do the same but with Trac and
Mercurial now.

~~~
wanorris
TFS is a below average source control system in an age when there are many
better choices. VSS, on the other hand, is an active threat to all of your
code.

At a previous employer, I was delighted by the switch to TFS, because it meant
we no longer had to worry about the VSS file store getting corrupted and
losing data. Now I'm on contract with another employer still using VSS, and we
should be cutting over to TFS soon. Once again, I will be delighted. Because
the below average is a welcome change from the flatly unacceptable.

~~~
pointyhat
Agree. I illustrated VSS to someone once by printing the source out and
throwing it in the bin. That got the point through.

