TFS woes

It's the little things that niggle me about Visual Studio (VS) and Team Foundation server (TFS) that make my daily use of them frustrating. I've used Visual Studio almost every working day of my life for the past 10+ years so I've seen it grow from a decent IDE to a bit of a monster in terms of functionality and size. Here's a small collection of things that still bug me today.

I've just defined my sprint in TFS. Now I want to check that the burndown report is there and the values are correct. Too bad - TFS reports run off the warehouse so it'll be a while before that's updated. How long is the "while" you ask? The answer appears to be "Never mind, none of your business. Just try again later." This affects every single report that you want to review after a change to a work item. It's a serious pain in the arse. TFS should install by default without a warehouse database but allow larger installations to opt into the warehouse replication if it suits their needs.

Today, I had to update the end date of my sprint. I know that's not normal, and it's not scrum and I should never do this, but hey, here in the real world, people are breaking the rules all the time. I updated the sprint work item at 8:50:59. I've requested an update of the burndown at 9:44, which shows me the same one it generated at 9:41:41 which claims that the "Data Updated" was at 9:25:02. Maybe it's my lack of training with the tools, but if I edit the sprint, I expect the burndown to change. I expect that change to be immediate. It's 2011 people; the days of waiting for your JCL to run overnight in an underground bunker should be over.

You're looking at your pending changes in TFS 2010 with Visual Studio 2010 Ultimate (yes, you're using Microsoft's state of the art development tools). The Undo menu option is directly below the compare menu option. Woopsie if you nudged the mouse before clicking eh? But no worries, there's a prompt for the undo; only trouble is, the default button is to confirm the undo. There is no undo of the undo silly; your work is toast, get over it.

You want to edit a file so you press Enter. Visual Studio now asks TFS to check out the file. But the TFS client asks the server to check it out. This is a synchronous call. You sit and wait for a response from the server before you can type. If the server's down or just having a bad day; guess what, so are you.

You open a solution file in VS but you're not connected to the network right now because you took your laptop to a meeting room and you didn't bother logging into the corporate WiFi. Well tough luck son, you're now working offline. No, connecting a cable at this point is futile; there is no retry, no abort/cancel, no option other than OK. You are already offline, even if you kill the process. You're screwed. It gets better. There will be no test by VS at intervals later to see if TFS is reachable and prompt you to go online. You'll suddenly realise, after a day of work that the files you've been editing (you should have noticed there was no checkout delay when you edited them) are now edited locally but not checked out. You say a silent prayer to any god who might be listening that nobody else has changed those files in the mean time or you'll have the devils own job merging their changes and yours. All because you opened a solution file whilst offline; you idiot!

You open the properties of a project file (this will open in a pane). The only "pane" in your mind is spelt PAIN as you try resize a pane whilst the properties are being loaded. Why? Because it won't work. The entire VS user interface is locked until that pane loads. I wonder sometimes, whether they did that on purpose to avoid unforeseen issues, and how much effort it took to make the ultimate user experience from hell.

Very often you do something and you're not sure if you really clicked the right thing because there's no feedback. The mouse cursor doesn't even change to a sand clock. That's the easiest thing in the world to do in Windows and they neglected to do it. Unforgivable.

Ever been to an MSDN presentation or road show? Ever notice how many people are asking what sort of laptop the presenter has? They want one that responds like that. We're all living out in the real world with significantly lower spec machines and we feel a pain they don't.

It's not that the little half seconds total up to huge amounts of time over the period of a week or a sprint (though of course they do). It's the constant resistance to your momentum in terms of working efficiently that eventually have you shouting abuse at the screen and wishing your could punch the living sh!t out of the person at Microsoft who decided to leave the cancel button enabled but not react to clicks on it whilst a long running process just chips away at your productivity.

There are many many many more instances of these sorts of niggles in VS that frustrate a developers life. And yet, there are a lot of things VS does well. It's by far the best IDE I've used, but these little things bug me because in my experience as a Windows developer, it's Microsoft who have told me over and over in MSDN articles to not use the UI thread for long running processes, and it's far from difficult. People who can make an IDE as complex as VS ought to be able to do better than lock the entire application when the content for single panel is loading. The VS team need someone doing UX for them, and that person needs to be senior in terms of decision making.