VS Team Suite or VS Pro + N[etc.]?

I was at a presentation last week for a customer who was considering using VS Pro 2005 with the full complement of N[tools] (and Cruise Control) over Visual Studio Team System for their next evolution of SDLC management.

It’s a prickly subject for me; not only because I work for Microsoft, so taking one stance would see me sacrifice one brother over another, but also because to me, the question of VSTS over VS Pro etc is not a feature slug fest, but a inquisition into integration (ahhh, love those sunset alliteratives ;))!

Anyway, so where am I going with this? About 4 years ago I was working for an framework company, where we built custom frameworks for use in software projects. A big part of our job was exercising the frameworks during development to ensure they were always water tight, based on a range of framework test scenarios. We did this by creating a COM component that implemented a set of interfaces that allowed the component to slot into a test harness runner, then wired it into the test run through an XML file. Our build process was also pretty custom; we leveraged the command line compilers heavily, but again, had COM components with lace up interfaces that slotted into a host process that managed the overall build. The same went on for deployment, reporting, bug tracking, etc. Essentially, we had a custom SDLC rig that became a project in itself to manage. When the N[x] generation of tools became mainstream, we hooked into them quick smart, but we still had a considerable amount of management overhead built into our SDLC.

Why was this a problem? Because alot of out SDLC process was in place to provide our customers with predictable quality. I used to hate having to rejig the build env each time we upgraded one of the moving components, and having to maintain all the dependencies between, for example, CruiseControl v.X and NAnt v.Y to use f(z).

The other problem I had was in reporting. I was constantly producing reports for customers on defect rates, build quality, test coverage. Getting this information from the segmented tools environment was non-trivial, and in addition to managing the env tools, we now had a swag of shim components instrumenting the env tools for reporting.

And the final straw came when we had to do defect accounting. What’s that? A tester (generally the customer) identifies a defect, and you need to track that back through the build, then through to the check-in, then the developer, to the change request. Why? Because if you’re trying to make money from your SDLC, you need to identify the where, who and why of how a defect came into being; then strengthen that part of the chain. If it takes you considerable time and effort to identify the weak link, then you’re going to have a) a weak process or b) an expensive correction process.

So when VSTS came out, and the linkages between the task management system, the source control system, the design and coding system, the build system, the test system, the deployment system, were all integrated, extensible and traceable, which dropped the cost of the SDLC correction and management process. That’s why I get excited about VSTS. Yes, VS Pro + N[etc.] will get you on your way to a good SDLC management process, but when compared to a fully integrated SDLC system, the choice becomes pretty clear, as does the delta value.

Any hoo, home time; food for thought I guesss :)