Wednesday, October 8, 2008

Am I excited for Microsoft TFS 2008?

**Warning: this post is work-related and probably going to be boring to most people.**

After loudly complaining about TFS 2005 today (for the nth time I got an error while checking in new files that ultimately unsafely killed the devenv.exe process, thank you very much), our QA manager asked me if I was excited about our future upgrade to TFS 2008. That's a good question because I know nothing about TFS 2008 and how it's different from TFS 2005. My initial thoughts:
  1. It can't possibly be worse, so bring it on!
  2. I'm excited about the .Net framework 3.5, but that says nothing about TFS.
I took it upon myself to find a better answer to that question, and here's what I found:

I am slightly disappointed in what I learned about TFS 2008 because it seems the main thing they focused on is CI and build automation. At first this sounds like a good thing, and it might be, but honestly it just shows me Microsoft is still the same stubborn behemoth that refuses to recognize the open source community despite the press they'd like you to believe. There are a hundred build automation tools out there that other shops have been using since .Net 1.0 came out in 2002. Why we need another (buggy) one from MS is beyond me, except to satisfy the "it's open source so I can't call support so my manager won't let me use it" crowd. I'm not suggesting that all open source is good and MS / profit hungry corporations are evil, but attempting to compete in a free wheel segment by reinventing said wheel in an inferior manner and adding a price tag on it is insane. If you're going to be a fast follower at least be a good one, ok Zune? I can only hope they fixed the bugs in the current "RC" version.

I just don't believe Microsoft knows anything about agile or CI in particular (would they have released TFS 2005 without it if they did?), and their reputation of not listening to customers has been proven fairly true in my experience, so I frankly don't expect their CI product to actually satisy our CI needs. No CI shop is the same, so we'll need to customize the process. Hopefully that will be less painful than checking in a file in TFS 2005, and won't require a PhD or a 900 page book to do successfully. I personally would like to see us keep the CC.Net implementation we have been working on. CC.Net has been around forever, is free, has good community support and decent documentation, is built by smarty pants nerds who update it regularly, and just works. It's simple. So, for that matter, are NAnt, JIRA (not free), Bugzilla (free but I prefer JIRA), CVS and/or Subversion, and Basecamp from my experience with them. Which leads me to my next point...

I'll stop complaining about MS the company now and shift my attention strictly to the TFS product / concept. Note that this isn't necessarily specific to TFS 2008, but nonetheless is part of my exploration for an answer. Q: What is TFS and why would anyone buy it / what is the competitive advantage? A: TFS exists, in a broad generalization, because Microsoft thought it would be smart to give their customers (software shops with more than 1 developer) the ability to have one mecca uber-place where
  1. their customer support / product teams track bugs and new features,
  2. their developers store code which implements said features and bugs in a team-friendly fashion without leaving their IDE,
  3. their QA teams pass or fail the items created in step a,
  4. their build manager can compile a version of the product containing the new feature or bug fix to be pushed to somewhere, and
  5. to a tiny degree, project managers can oversee this entire process from start to finish.
In short, the entire software development process under one roof. What a huge undertaking. That's all well and good, but means TFS essentially then acts as a bug tracking system, a source control repository, is integrated well with Visual Studio (a huge product in its own right) as a plugin, and acts in a minor way as a project management tool. As far as I'm concerned, TFS 2005 only satisfies 1 and 3 in a halfway decent way, and didn't even attempt 4 (kudos to TFS 2008), which means all Microsoft did was recreate JIRA or Bugzilla. What strikes me as especially bizarre about TFS as a product is that there are already free products out there that satisfy the 4 bullets above and cost nothing. What's the competitive advantage then? Only that it's all in one mecca uber-place. Hmm... I honestly don't mind having more than one application open at one time on my machine, and would happily trade 5 tiny-footprint apps that function well for 1 giant, slow, buggy one. It seems to me TFS is suffering from a severe lack of competitive advantage... certainly not enough to warrant the licences, extra SQL servers, CPU and RAM rape, etc. If they actually do manage to jam the entire software factory under one roof then it'll probably just remind people of how over-complicated their jobs are, but we'll see.

A few other bones to pick as a developer using TFS:
  • My entire team regularly experiences bugs which crash Visual Studio while checking in code. If they fixed any of those, then YES, I am excited about TFS 2008.
  • Since TFS already knows which tasks are assigned to me (or anyone else if I happen to be working on a file for my neighbor), why can't I associate files to tasks before I check them in? This would eliminate the need to track that on a spreadsheet or text file (oops! that's another app I have open) until I check in. I would really like to be able to click a "Resolve a Task" button which lets me pick a task and knows which files to check in based on my selection. How about that for competitive advantage? As far as I can find on the web, TFS 2008 does NOT have this feature. Surprise...
  • The way that TFS 2005 alerts you of file conflicts on check-in sucks. TFS should only fail a check-in if it can't merge and check in at the same time for all files being checked in. I constantly have check-ins fail only to be alerted that TFS can auto-merge all files for me. If you can, then just do it. If they fixed the check-in process, then YES, I am excited about TFS 2008.
  • The TFS merge tool sucks. Me and most of my teammates have installed other merge tools (free, by the way) to do our merging outside of TFS (oops! that's another app I have open). If they improved the merge tool in TFS 2008, then... I really don't care because it probably still sucks.
I should stop now. Am I excited? Let's just say the jury is still out.

2 comments:

Anonymous said...

Amen - I couldn't agree more.

Concept - nice, simple building blocks with well-documented integration points.

Oh wait, then you wouldn't be forced to pick the buggy commercial implementation of anything, so there goes Microsoft's market...

Anonymous said...

This all sounds quite familiar.

I'm concerned about upgrading from tfs2005 to tfs2008, or even 2010, when the issues I'm having don't seem to have been addressed.

I also don't understand what's good about having everything in one place. I just don't see the advantage. I find it painful to get to source control, or bug tracking, and then back to coding.

Alt tab leaves things as they are, so I can flip between the systems leaving them in whatever state I want. Not to mention, when VS is tied up, I can still do something else, rather than twiddling my thumbs, which I seem to be doing a lot of since moving to tfs.

Ok, I could open another instance, or more, of VS, and just do bugs in that, or VC in that, but then when I alt tab, they all look the same!

What's the advantage? I can select a workitem from a list, rather than type a number in? Yes, that's nice. But, if I only have the number, I have to select query all, search for number, and that takes forever!

Ok, I like the fact that TFS automatically checks out files on edit, it means I can't easily forget to check them in, as they'll be in pending files. Unlike p4, where it's easy to forget to check something in. Then, with tortoiseSVN, you'll see all modified files anyhow. This seems to be a much better approach.

Not to mention, if I want to see what's changed in the repo before I "get latest", and run History on the branch, i get a filename list in the log (if I'm lucky) but with no context menu. So, I want to look at the changes for a few files, and I hve to look up each file in the hierarchy?

Not to mention revert, and server exceptions on attempting to revert using commandline tools. Is revert such an unused feature?

And not to mention merge crashes.