As a developer, I love Microsoft Team Foundation Server. As a manager, I hate it.
Why? Bug tracking.
“But TFS does bug tracking,” you say. Sure it does. So let me try to explain why Microsoft’s brand of bug tracking just isn’t going to get the job done. I’ll start with my personal opinions about bug tracking.
Bug tracking is one of the basic life-support functions in software development. I’d rank it second after Source Code Control as far as critical support functions. To put it bluntly, there’s just no reason not to have a bug tracking system these days. There are hundreds of very good systems out there, and you can get most of them free in a box of breakfast cereal.
It’s pretty common, in my experience, for people to argue against logging bugs. There’s a perception that logging a bug is a big, hairy deal, or maybe they want to keep the count low in their “real” bug database so their numbers look good. Bull-pucky, I say. Log everything. If a bug occurs and it doesn’t get recorded, it never happened.
Sure, you’re going to get some bad bugs. You’re going to get some duplicates. You’re going to get some bugs you can’t reproduce.
If you log a bug and have to close it because it’s a bad bug, you spend some time doing so. Bug if you don’t log a bug, you can never reverse that decision. In fairness, you’ll usually want to have *something* in a report that’s actionable, but I really prefer to set the bar low so I sweep more bugs into the net. I can far more easily wipe out the bad than I can make up for lack of data if there’s something going on that I’m not seeing.
You may have inferred by this point that I prefer to let most, if not all users and testers enter bugs. Right on. Again, this is to help gather information as close to the source as possible. And yes, again, this increases the chance for junk data. And yes, yet again, the alternative is no data. If you make it easy for lots of people to give you feedback, some of them will give you feedback. If you make it difficult, damned few will give you any at all. You’re in the dark — probably with a false sense of confidence about the state of your system. “Look – no bugs logged in the last week! We’re perfect!” Sure, you are.
Ok, so that’s how I feel about bugs. Feel free to argue amongst yourself, or even with me. 😉
Back to TFS. Like I said, they have a bug tracker, so what’s the problem? Not a thing, if you happen to be a developer with TFS already running as part of your IDE. If you’re not a developer, here’s what you’ve got to do to use TFS:
- Buy a license. Yes, if you want to log a bug, you need a full TFS client license. Just to log a bug. JUST TO LOG A BUG.
- Since you have to buy a license, you’re probably going to need to justify that license to somebody (not that I’ve run into that brick wall recently, or anything….). Quick review: you’re going to be asked to make a business case for purchasing a client license for someone so they can LOG A BUG!! Let me know how that goes for you, ok?
- Now you need to get Team Explorer installed on the workstation of the person who’s supposed to log the bug. Oh, no — you can’t just browse to a web page to do this (despite the fact that TFS makes heavy use of SharePoint). Is any of this making sense to you? Astute readers will observe at this point that there are add-on software components available to web-enable TFS. I’ll observe right back at you that the very fact that this is an add-on tells you something about whether Microsoft gets how this software should be used.
- Now, your user is ready to log a bug. After they open Team Explorer. On the machine where it’s installed. Oh, they’re at a different machine now? Maybe they’re testing on a Mac? Nuts. Well, write everything down and log it when you get back to your desk. Poof! Your bug just disappeared, because 99 out of 100 users are just going to say, “why bother?” And they’d be right, of course.
Come on, Microsoft — think this through and get it fixed. Now. Please.
In the mean time, use this.