Microsoft Team System Combines Established With New
At VSLive! and its affiliated conferences (I am speaking at the
Software Architecture Summit), Microsoft will be talking more about its big developer release of the year, Visual Studio 2005 and the
Visual Studio Team System. While I normally write about Java topics, or at least remain technology-neutral, I have some insight on these new products that might be helpful to those looking at them for the first time.
I was one of a select group that had detailed information on Visual Studio 2005 and the Visual Studio Team System well before its public announcement at Tech•Ed in 2004. I worked at Compuware's NuMega Lab at the time, and Microsoft briefed us and other development tool partners on its plans under NDA (nondisclosure agreement). For my colleagues, it meant that Microsoft was giving fair warning that it was getting ready to encroach on core features that we had relied on for many years. Our response was to conceive of and build new products, while still hoping that the maturity of the existing ones was sufficient to add value to developers. That theory will be put to the test in the next 12 months.
Visual Studio 2005 remains pretty much Visual Studio. The Team System adds most of the new features to the development environment. These include performance and memory profiling, code coverage, static source-code analysis, and automated load testing. These are supported by a repository and source-code control system (
not SourceSafe, Microsoft is meticulous about pointing out).
But that's just the starting point. The source-code control is rules-based, so you can establish prerequisites for checking in code. You can define rules for meeting certain milestones during the development process, and assess your quality over time by using standard or custom measures.
The Team System is pure Microsoft. It takes many established concepts, but combines them in unique and interesting ways. In doing so, it defines an application development lifecycle that reaches the pinnacle of automation possible with today's technology.
For instance, the application development lifecycle starts with the infrastructure of the production environment—what servers are inside the DMZ vs. outside it, what ports are turned on, what account privileges are permitted, and things like that. This is expressed diagrammatically, with metadata, so that a diagram of the application architecture can be compared against it for compatibility. If there is a mismatch, the architect must change that part of the application, or negotiate with the holders of the production environment to make the necessary changes.
One of the primary reasons an application makes it all the way into production and then fails to work, or fails to perform, is that the developers were not sufficiently cognizant of the deployment environment or user patterns. Microsoft's approach with Team System is to enable the development team to work from within existing constraints from the beginning, to greatly reduce the likelihood of failure at the end.
As you might expect, there are several caveats to that bright vision. First, the bulk of these features work only with code developed in Visual Studio 2005, so to take full advantage of those features means that all developers must work in that version, and on code developed or fully ported there. For most teams, it will take at least a couple years to get to that point.
Second, as a first release, the Team System will lack the reliability and breadth of features that will make it truly useful. It's only through years of actual use, feedback, and improvements that such a system can become a backbone of the development lifecycle.
There is a larger issue, at least with most of the development with which I am familiar. Many development teams simply don't work this way. It has less to do with tools availability than organizational and cultural issues, which will be much more resistant to change. Automating the development workflow can lead to some incremental efficiencies, but won't reconcile the conflicting goals and priorities of those who build software, those who run systems, and those who use software.
And there is no longer any question that Microsoft is focusing the bulk of its vast resources on custom software development at the enterprise level. This is great news for those who have been struggling to employ Microsoft technologies for enterprise-scalable applications, but less relevant to the force of ISVs, startups, and individual developers who were key in making Microsoft the development force that it is. Most industry observers believe that enterprise custom software development is where the growth and the money reside for the foreseeable future. Microsoft, like many others, is chasing that engine. I hope that it doesn't leave the rest of its community behind in the process.
Posted by Peter Varhol on 01/31/2005