Becoming a Team Player

You can still code with the big coders without breaking the bank and wasting it on tools you may never use.

We must all hang together, or most assuredly we shall all hang separately.
— Attributed to Benjamin Franklin on the occasion of the signing of the "Declaration of Independence"

In Franklin's time, of course, it was the British crown that was emphasizing the value of teamwork for the rebellious colonists. Nowadays, many developers are getting a hard sell on teamwork from an organization about as large as the British Empire ever was (and one perceived by some as being just about as oppressive, for that matter): Microsoft. It's difficult to open a magazine these days without running across an ad promoting Visual Studio Team System in its various editions.

One thing is clear: Microsoft definitely believes in the value of teamwork. If you just walk in off the street and plunk down your money to pay the full list price for a copy of Visual Studio 2005 Team Suite with MSDN Premium Subscription, it'll cost you a cool $10,939 (you can, by the way, save about half that by signing up for a MSDN Universal subscription before VS 2005 is released). Now, if you're working in a Fortune 500 corporation somewhere with a fat IT budget, that may be a perfectly reasonable price to pay to equip one of your superstars who needs to be able to move back and forth between architect, developer, and tester roles. But there are an awful lot of developers who aren't in that position (and who aren't, apparently, in the target market for Visual Studio Team System, judging by the pricing).

Fortunately for the rest of us, Microsoft isn't the only game in town. By promoting the benefits of a good set of development tools, and then pricing their own set of tools out of reach of many developers, Microsoft has encouraged comparison shopping. Ironically, the end result may be to erode the market share of Visual Studio among developers who might otherwise have remained content to continue faithfully renewing their MSDN subscriptions every year.

Time for a Radical Change?
If you're really fed up with Microsoft, there's always Java. One big plus to moving to the Java camp is the Eclipse IDE Eclipse started small a few years ago, but thanks to support from some big players and general community interest, it's turned into one of the big, open-source success stories. Although Eclipse is theoretically a general-purpose IDE that's not tied into any particular language, the Java community has embraced it so well as to make it a de facto standard over there. If you do decide to move to Java, you can use Eclipse as an IDE for free, and get all sorts of goodies in your new free IDE: Whether it's Java development, testing tools, UML 2.0 diagramming, J2EE support, XML editing, or one of dozens of other things, someone has either built it or is working on it for the Eclipse IDE.

But remember, the grass is generally greener on the other side of the fence. I've only puttered with Eclipse myself, but I'd be astounded if every possible combination of plugins and languages worked perfectly together every time. More likely, you'll face the same issues that you do in any other continually churning set of open-source projects: Sooner or later something will break and you'll spend a few hours or a few days of nonproductive time sorting out versioning issues. Sure, there will be helpful community people to help you sort things out, but the fact remains that many hands tend to make brittle software.

And of course Java, with or without Eclipse, isn't the only other game in town. Smalltalk has its own vocal proponents, as does just about every other language out there. If you're willing to shop around, you'll find no shortage of development environments. Remember, though, that it's going to be tougher to get support and extensions for some of the smaller niche players. And of course, if you switch from .NET to something else, you kiss your built-up skills and knowledge good-bye and get to start back up the learning curve anew.

Maybe Just a New IDE?
So, you've decided to stick with .NET. That still doesn't mean that you need to stick with Visual Studio for development. Building .NET applications is documented well enough that several other companies and groups have stepped up to provide you with choices in the IDE world (assuming that you don't want to retreat all the way to a text editor for your coding). SharpDevelop provides an open source (GPL) IDE, while Omnicore X-develop is a commercial alternative that can both .NET and Java code, and that features built-in refactoring.

But though they offer reasonably attractive environments for building .NET applications, neither SharpDevelop nor X-develop have any collaboration, testing, or modeling features to challenge those of Team System. If you want an IDE that offers an alternative on that level, you can look at IBM Rational XDE or Borland Together. Of course, then you're right back in the thousands of dollars per developer pricing neighborhood. Enterprise functionality from enterprise vendors doesn't come cheap in today's market.

Building Your Own Team System
Perhaps the most attractive alternative for most developers familiar with Visual Studio is to build their own version of Team System. I don't so much mean that you should try to recreate Microsoft's entire integrated suite of functionality with uniform look and feel (though the NTeam project is trying to do just that), but that you should choose the parts that are important to you and hunt down alternatives. There are free or low-cost alternatives for almost every piece of Team System's functionality. Here's what you get if you spend the money to buy the full Team Suite:

  • Modeling
  • Code analysis
  • Code profiling
  • Unit testing
  • Code coverage
  • Test case management
  • Load testing
  • Source code control

Modeling is probably the area where you'll have the most trouble finding any equivalent tools. That's because Microsoft is largely inventing their own modeling language, rather than going with anything standard. But there are certainly alternatives — notably, there are a number of UML-based design tools that integrate with Visual Studio .NET. For example, SDE for Visual Studio .NET starts at $59. Note that I'm not trying to be exhaustive with my list of tools here, just pointing out examples in each category; if you hunt around you'll find plenty more. One good resource for such hunting is SharpToolbox, a site devoted to collecting .NET tools.

Code analysis tools include Microsoft's own FxCop (free from and FMS's commercial Total .NET Analyzer, which will set you back $499. Tools in this category can help you find suspicious bits of code that probably won't do what you have in mind, as well as violations of your own corporate coding standard.

For code profiling — finding slow or memory-hogging bits of code — you can try the $295 ANTS Profiler, Red Gate also sells the $495 ANTS Load, to handle load testing. Such testing is an important part of deploying large projects that will be hit by many simultaneous clients.

Unit testing is one area where you needn't pay for a tool (though there are commercial alternatives). There are plenty of good free tools out there, starting with the venerable NUnit and including the Visual Studio integrated TestDriven .NET Whatever you do, don't develop code without unit testing.

For code coverage, NCover is a very widely used and free tool. It will help tell you which areas of your code are covered by your tests and, more importantly, which areas you're not testing at all.

Test case management is an area where I haven't seen any good free alternatives yet. NUnit and similar tools offer immediate feedback on which tests are failing at any given moment, but for long-range tracking most developers will likely just roll their own database or spreadsheet.

Finally, source code control is a solved problem. In fact, it's been solved dozens of times over. For free systems, you should probably look at Subversion and if you want your source code control in the IDE, the Ankh plug-in But there are lots of other choices in this area, both free and commercial. The CM Crossroads site has an amazing amount of information on the various systems out there for configuration management, which includes source code control.

The Bottom Line
Personally, I'm going with the "build your own" approach. I see two big advantages to this a la carte approach to picking tools to extend my development IDE. First, I can pick (and pay for) only the tools that I actually want and need for my own development efforts. There are some things in the big Team Suite box that I personally would never touch. For example, none of the development work I'm doing right now is in real need of load testing. This means I save money over buying the whole shebang from Microsoft, and I avoid cluttering my brain with things I'll never use.

Second, by shopping around I can choose truly best-of-breed tools in each category that I do use. Microsoft has a batch of smart people working for it, but for all the effort put into it, VSTS is a version 1.0 product. It's not going to be perfect out of the starting gate, and Redmond isn't the only source of innovation in the world. By bundling everything together, Microsoft has made it less attractive (at least for me). I won't write Team System off, but I'm going to wait and see what it looks like after it's got two or three versions under its belt. Meanwhile, there are plenty of other alternatives for high-end professional .NET development — at a substantial savings.

Want to read more of Mike's work? Visit his Larkware site for daily updates at

comments powered by Disqus
Most   Popular

SharePoint Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.