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 http://www.eclipse.org/.
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).
provides an open source (GPL) IDE, while Omnicore X-develop http://www.omnicore.com/index.jsp
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:
- 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 http://www.visual-paradigm.com/product/sde/vs/
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
a site devoted to collecting .NET tools.
Code analysis tools include Microsoft's own FxCop (free from http://www.gotdotnet.com/team/fxcop/)
and FMS's commercial Total .NET Analyzer http://www.fmsinc.com/dotnet/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 http://www.red-gate.com/code_profiling.htm,
Red Gate also sells the $495 ANTS Load http://www.red-gate.com/dotnet/load_testing.htm,
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 http://nunit.org/
and including the Visual Studio integrated TestDriven .NET http://www.testdriven.net/.
Whatever you do, don't develop code without unit testing.
For code coverage, NCover http://ncover.sourceforge.net/
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 http://subversion.tigris.org/
and if you want your source code control in the IDE, the Ankh plug-in
there are lots of other choices in this area, both free and commercial.
The CM Crossroads site http://www.cmcrossroads.com/
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 http://www.larkware.com.