Robert – thanks for bringing up the issue of integration. This is actually the real sore point for my customers. TFS was chosen not to satisfy Developer concerns, but for the Admin/CM folks. They wanted it because it was a “one-tool” fix for their previous setup. This particular contract has been running for upwards of 15 years with largely the same group of folks, using separate tools for their needs: Dimensions/Rational for CM, custom test/build scripts and NUnit for testing/building, and Source Safe for SC, along with a few other tools customized for Requirements, risk assessment and other Admin activities. They put in a lot of effort to integrate all these, the focus being reports for the end customer. So by the sales material, this was a prime group for a TFS “upgrade”. The experience has so far been so-so. So let me give you a brief rundown on the major issues.

Developers:
The developers here are like most, they don’t really care what you give them to work with, they figure it out since they are really only concerned to get the coding done and pass testing. The things that Casey focused on are right on the mark with our experience here. However, there are some other problems. Most of the applications being worked are legacy apps built in VS 2003/.Net 1.1 and VB6/ASP 3.0. Despite implementing the MSSCCI provider, etc. TFS 2008 just does not play well with the legacy apps. For instance, if you have a Web App in 2003, the default behavior upon a check-out/get-latest is to place the web project automatically in the Inetpub path, while other non-web projects are placed in your designated Workspace path. We found this out accidentally. This is partly a problem since if there are multiple branches for different phases of work then we can’t very well have the same Inetpub path and root name; and since the product delivered to testing must have the correct paths/naming then we can’t just make different copies under different virtual directories, etc. There’s been a lot of heartache in figuring out how to successfully do work, and there turns out to be lots of different work-arounds that developers have come up with. Other problems involve the Workspaces – it’s a great idea, but all of us here have come to the conclusion that the best policy is to have one workspace at the TFS root level, and let it mirror the Server’s Project setup. All that stuff in the MS sales/training materials about doing fancy things with Workspaces has been largely thrown out. Another big heartburn is Merging/Branching and the lack of a roll-back (I know this is coming in 2010).

CM/Admin Issues:
Part of the problem here has been the local implementation of TFS. TFS was sold to my customer as a comprehensive suite but the expectations were not handled well. Granted, the previous suite of tools and procedures took 15 years to customize and tweak, but still, expectations are key here – not just how my company sold TFS, but how TFS sells itself. Problems here focus mostly on prep work – my customer was ill informed and not prepared for the amount of work required before live data was actually entered. For instance, having properly nailed down Work Item template definitions was not properly sold to them. As a result, we’ve been making up the Work Items as we go along, and once data is present, the work required to radically update a WIT goes up 3 or 4 fold. Migration of data has proved problematic as well, most of it requiring custom code since the Excel option has a number of issues (cannot automatically port over links/attachments; it’s a RAM hog; can only do one Project at a time, etc.). Basically, they thought that once the TFS server was set up and permissions implemented, then it would be a cinch to start using, not that it would take several weeks of prep work. The OOTB implementation is what was sold, but this just does not cut it. Customization is really the catch word for all of TFS. My customer and I have had to get used to the fact that when they want TFS to do something that their old tools used to do, the answer invariably is “yes, but that requires a customization”, and this usually requires custom coding, and since half the users use Web Access, it often requires one for Windows and one for ASP.

As to Integration, from my experience so far, TFS is only NOMINALLY integrated. It’s not one tool that accomplishes all the roles of a SDLC, it’s actually 4 different tools jerry-rigged together: 1) the VSTS IDE and TFS Team Explorer or Web Access for communication (with minor annoying functionality differences, btw), 2) a SQL OLTP for Source Control and WI data entry, 3) OLAP and SSRS for Reporting, and 4) WSS and a Share Point site (two of them counting Web Access) for Document handling (anything else?). What we’ve been finding is that our actual experience suggests that TFS should thus have its work split up – a SQL DBA is needed to handle various SQL issues, permissions, server deployment, etc.; an SSBI specialist is needed to make reports since MDX and OLAP are supposed to be used (MS has explicitly said not to base reports on the OLTP as this is guaranteed to change); a Share Point/Web Parts person to handle customizations here; and a normal Developer to handle all the customizations required to get TFS workable for special needs. In addition, since the Work Item Template definitions are just XML files and tedious to make/update, CM folks would be best to take charge of these. In fact, my CM customer here has requested I train them on this, since the work they would do is not that much different than what they used to do to with Rational. Considering all this, the question presents itself – DOES THIS REALLY REPRESENT INTEGRATION?

Another major issue is how to handle Document versioning and WI/SC integration – we have still yet to tackle this problem, and this is major considering the documentation needs this contract has. There are 4 (FOUR!) different ways to handle documents in the TFS suite, each involving a different DB storage and set of functionalities – 1) As a versioned item, subject to collocation with development files and partaking in Checking Out/In and Branching/Merging, but this is only in binary and hence can’t be used for comparisons, etc.; 2) as a file attachment to a Work Item that is stored as a part of the Work Item’s metadata (again binary); 3) in the Share Point portion of TFS, allowing for versioning, but then documents can’t be linked with individual Applications/WorkItems let alone Branches/Releases; 4) or you can use the Web Access version – this is also Share Point, but uses a different source DB than the default Project Portal. This is a major hole for my customer, because with their previous admin setup they were able to easily tie in Document Versioning with specific Releases and even Branches, etc. So far, we have not figured out how to do this with TFS.

UI issues & Customization: One really big issue is the primitive nature of the Work Item controls. This is particularly galling given that in the Reports the same type of controls (drop-downs, labels, etc.) are fairly up-to-date, so you get to have good filtering controls for reports, but not for actually data entry. For instance, the WIT combobox control does not have the standard hidden field that has become normal for Windows and Web applications – as a result, things like sorting, or having an ID column separate from the display column require customization or in some cases have to be dispensed with. I think my customer had a reasonable expectation that this would be standard for TFS WIT controls as well. Other things, like the lack of a multiple check box combo also require customization, even though on the Reporting side, this kind of control is standard – at the very least the customer is frustrated by the ability to custom filter, but not to add data in a like manner. Another thing that we can’t use is the HTML field type – I have figured out a fix for Reports, but the query results grid does not properly encoded the HTML mark up in an HTML field type, so in queries (which are used much more than Reports) any such field has the markup showing literally. As a result, we’ve had to go through all the WIT’s and remove this field type and replace it with PlainText. I have a lot more, about 2 pages work of such bugs.

Some other minor holes – 1) The Email notification uses the Display Name from the AD for fields like AssignedTo, and while the ChangerID uses the unique SID, the Display Name has the potential to be repeated – we’ve actually had such a case, and it was quite a bit of work to make sure the right person got the email – this is again related to the poor quality of the Work Item controls – a combobox with a standard hidden identity field containing the SID would fix the problem; 2) We’ve found that we can’t use the Automatic Work Item State transition change on Check in – you can only really have one transition defined on a checkin in the Work Item flow, and the work flows for my customer are highly customized and so we have to remove any checkin rules for state changes. 3) My customer and their customer have their own Work Item ID formats and their own numbering system that they need to carry over from their previous databases. We have successfully worked around this and they can have their own non-TFS ID formats with auto numbering, but the problem remains that we cannot integrate this number into things like Work Item linking, finding WI’s to associate to on Checkin, showing these custom IDs in Emails, etc. So there is a limit to how the customizations can be used to override things they don’t want to see. They’re getting used to it, but they still don’t like it.

Anyway, thanks for providing a platform to rant a bit about some of the frustrations I’ve found working with TFS.

I’m not usually one to get in the middle of a fantastic breakup, but sometimes, you just gotta get involved.

You definitely are deeper than other source control systems I’ve known. If by deeper you mean overly controlling, nagging, and micro-managing. Problem is, I’ve got a wife for that. Oh, and an IDE. All I want from you is 1 thing. That’s what I pay you the big bucks for.

While we’re talking about nagging, don’t go blaming your mother-in-law for your crap. I want my source control to be practically invisible. If I wanted bondage, I’d talk to Rational. And you, sir, are no Rational.

Funny that you talk about a non-existent user interface, TFS. You look like you put your makeup on as a passenger at a Monster Truck Rally. If I wanted pretty, I’d talk to Perforce. And you, sir, are no Perforce.

Subversion isn’t the type of source control to go down on guys like me, I’ve got memories of Visual SourceSafe for that. Isn’t that your cousin? Or is it wife? Hell it could be both, it’s all pretty incestuous at Redmond.

Look, I’m just looking for one thing when I take a source control tool out. I don’t need commitment, love, flowers and romance. I’m just looking to get down to business. And frankly, you’re lacking in that department. All the chitchat and the nagging and the “Did you floss your teeth” crap is too much.

Don’t be mad, baby. You can’t help it that SourceSafe is your cousin/wife.

Hugs,
All the Source Control Tools I’ve Loved Before

Maybe in a few years, like 2010, when you (TFS) are a little more mature, we can talk again. I’m not saying definitely, but maybe. For now, though, I think it’s on our mutual interests that we part ways.

This is the end for now. You’re more than welcome to hang out with my friends, but I personally don’t want to see you that often. I hope you understand.

I may give Subversion a call. I honestly think that she’s a little more experienced and that you still have some growing up to do.

The other issue was not getting what you ask for. You are right that TFS won’t automatically give you code that it thinks you already have. I’m not really aware of any systems that work exactly the way it sounds like you want. No system can do this reliably.

Say a file TFS thinks you have is missing or edited – but you didn’t use the “delete” or “edit” command to do that – and you ask for it again. The “right” thing depends on your intent which TFS cannot infer.

Is over-writing your change right? Is implying a delete the right thing? Is pending an edit the right thing? The TFS workflow is the checkout/commit model. Subversion uses a different model but has many of the same restrictions.

In the end the safe behavior is to not guess what the user meant when it could result in data lose (say you were working offline and forgot to run “tfpt online” to detect offline changes – running a get should overwrite your changes).

If you have a file you need to get and TFS won’t give it because it thinks you already have it you need to use the /force (/f) parameter to “get” to let TFS know your intent. If you want it to over-write the file without the resolve dialog you can use the /overwrite (/i) parameter.

Ultimately what’s important is that you are using something for version control. If it’s not TFS then Subversion is a great choice. I spend a lot of time hacking Ruby and have really come to appreciate Git as well.

Perhaps in the future you will get another chance to look at TFS and find it more to your liking.

One thing you didn’t cover though is the integration story. I’m curious if you are just giving up on version control or if you are also giving up on workitem tracking, team build and the integration with reports and SharePoint.

Anyway – all the best with your new relationship.

Robert.

First – well written and humorous post. I think you called out some very real (and very important) issues that people frequently have with TFS (and other version control systems, in fairness). I hope you will be somewhat happy to know that we have heard this feedback loud and clear and made very real investments in improving these areas in the next release (2010). Totally doesn’t help you now – I get that. Sorry.

As far as resolving conflicts go – moving to SVN isn’t going to change that. If there are conflicting changes you need to resolve them. It sounds like a part of your process that might be missing is performing a “get” before checking in. No matter what system you are using your base version at checkin should be the tip (or you risk losing data which would make everyone sad). When doing a get you can auto-resolve the conflicts and only deal with those thar require manual resolution.

The whole issue about needing a link workitem on checkin – well, TFS was right there. That is something that your team project admin configured and if you’re not happy with it you can override the checkin policy (and accept whatever the consequences of that are – i.e. hassles from your peers/manager/etc). Or go complain to your project admin about it.

Personally I’m a big fan of giving people the tools to do the right thing and trusting them to do it. So let them link bugs and trust they will when it’s appropriate, but don’t create rules that say they have to. Those rules, as you have pointed out, get in the way of good flow.

As for the nagging… I guess that’s just how my administrators brought me up. I don’t have to be that way. I can be different, but they just configured me this way. If you don’t like it, talk to them.

Well, go on and call SVN. You always liked them cheap and shallow anyway. She’s doesn’t even have a real user interface… just an extension of a shell of one. But whatever… If that’s what makes you happy. Just don’t come running back to me begging for the stability of our relationship when she finally goes down on you and it’s, um, not quite what you had envisioned.

Signed,

TFS