Let me start by stating I’m kind of a crusty, old-school software engineer. I’m always skeptical about the "next great product" because I’ve seen too many products and technologies fail to live up to their hype. I’ve used dozens of bug tracking tools over the years. So, when I decided to investigate the new Microsoft Visual Studio Team System (VSTS), my expectations were low. Very, very low. But let me cut to the chase and say that VSTS absolutely impressed me. This is one awesome product. VSTS has a ton of features but here I’m going to just describe how VSTS is used for bug tracking. Click on the image at the bottom of this blog entry to see a screenshot of the new bug tracking feature.
Here’s a bit of background context. When I was first working at Microsoft in the mid-1990s, the standard bug tracking tool was an internally developed tool named RAID. The tool’s name was not an acronym; it was a reference to the insecticide product which kills bugs. Nobody I’ve ever talked to knew exactly when RAID was created but the consensus is that it was developed somewhere about 1993. RAID was a great tool for the time, when Microsoft was a relatively small company, with relatively few products. The problem with RAID was that is was somewhat difficult for different, but related, product groups to coordinate their bugs. Next came a tool named Product Studio about mid-2001. So that it could work between groups, Product Studio was completely integrated into the internal Microsoft network — so much so that the product actually required changes to the Active Directory schema! Although Product Studio was an improvement over RAID in some ways, it was troublesome to manage and had quite a few bugs early on. It was clear as early as 2002 that Product Studio was not going to be a long term bug-tracking solution at Microsoft. In March of 2006, Product Studio was officially discontinued in favor of the new VS Team System.
Visual Studio 2005 shipped in, not surprisingly, 2005. One of the editions is Visual Studio Team System. The bug tracking components of VSTS are called Visual Studio Team Foundation Server (on the server side), and Visual Studio Team Explorer (on the client side). It’s not quite clear what to call this system — is it Foundation Server (FS), or is it Team Explorer (TE), or is it Team System (TS)? Anyway, based on my early experience with the system, I am particularly impressed by three things. First, I really like the way Team Explorer is integrated into Visual Studio. If you check out the screenshot at the bottom of this entry you’ll see that TE is hosted inside VS. No more need for a completely separate tool. Second, I really like the way FS is integrated with Windows. It is really easy to manage users, groups, and permissions because they’re all based on Windows and Active Directory. No more separate user lists, password lists, group lists, individual permissions management, and so on. Third, I really like the way that FS is almost totally customizable via XML-based template configuration files. For example, I was stunned that the default configuration setting did not include a bug severity field. But I quickly figured out how to add a severity field.
Just so you don’t think I’m a Microsoft marketing hack, let me point out that VSTS isn’t perfect. In particular, installation could have been a little bit better documented with some screenshots, the system’s overall performance is adequate at best, and I am disappointed that there isn’t an out-of-the-box Web interface to Foundation Server. Based on the modular architecture, I have no doubts that I can pretty easily craft a simple Web page interface to FS. However, I shouldn’t have to do that from scratch. So anyway, bottom line: for working in a Microsoft environment, Visual Studio is (so far) clearly the best system for bug tracking I’ve ever seen.