Let’s settle this up front. Microsoft has let its developers down. During the past few years, the company has left a trail of broken promises: a .Net-centered operating system; a broad stack of managed, .Net-based server applications; effortless targeting of everything from servers to cell phones; an egalitarian approach to programming languages; and a new, revolutionarily productive, framework-aware IDE.
All of its pomp and preening attracted a crowd, but Microsoft’s grand, united procession split into smaller, scattered parades. Instead of pulling the Microsoft development community together, the .Net initiative and Visual Studio .Net have in some ways increased fragmentation and distressed developers with major changes that seemed arbitrary. Meanwhile, the Java and open source communities have worked hard to increase the attractiveness of their environments to the degree that some traditionally loyal Microsoft developers have acquired a chronic case of wandering eye.
Microsoft is betting that Visual Studio 2005 (code-named “Whidbey”) in conjunction with the new Visual Studio Team life-cycle management system announced last week will revive developer enthusiasm — and rebuild the company’s credibility for expensive future ventures such as the Longhorn operating systems and the Yukon edition of SQL Server. Although neither VS 2005 nor VS Team ships until next year, a deep dive into betas and intense discussions with Microsoft have convinced us that Redmond has been listening hard to both enterprise developers and their managers.
Turning back and forging ahead
Microsoft is mounting a two-pronged offensive to win back its enterprise development credentials. First, with VS 2005, it’s trying to retain individual developers on the verge of straying elsewhere. VS 2005 restores most of the exquisitely balanced feel of VS 6: relaxed yet productive, knowing yet submissive, the unobtrusive workmate who pulls you out of a fire the instant you call for help. Remember Visual Basic? Visual C++? Visual InterDev? They’ve grown up a bit since developers last saw them, but they’re coming home in VS 2005.
The second line of attack goes beyond the developer’s desktop to encompass life-cycle and project management. Visual Studio Team Foundation is the server-based integration and services platform, and Visual Studio Team System is a suite of client components that participants will use to plug into the team environment. (For brevity, the combined solution is referred to here as VS Team.)
VS Team is Microsoft’s first attempt to get directly involved in most stages of the enterprise software development life cycle. And its reach is broad. Microsoft plans to incorporate design, planning, project management, enterprise-grade source-code control, coding, static analysis, profiling, functional and load testing, infrastructure design and validation, deployment, and work-item tracking into VS Team’s fully loaded configuration.
The way we were
Whereas VS Team charts new territory for Microsoft, VS 2005 cultivates familiar ground. The languages and tools in VS 2005 balance productivity and code purity in a way that fits the rapid development of business applications. Not surprisingly, Visual C# and Visual J# pick up new features. But Visual Basic 2005 and Visual C++ 2005 are reborn. Microsoft also sneaked the functionality of Visual InterDev back into the toolset, with some Dreamweaver-like tweaks added. And the ClickOnce installer puts the complexities of preparation for distribution and deployment in the hands of the development environment, where it belongs.
Just as significant, Microsoft is putting Visual C++ 2005 back at the top of the food chain. When Microsoft released VS .Net, it assumed that C++ developers would jump to C# en masse. Unmanaged — compiled to machine instructions — code was deemed primitive, dangerous, and exploitable. VS .Net derailed Visual C++ to encourage C++ developers to evolve into more civilized and enlightened C# beings.
New efforts on behalf of Visual C++ 2005 suggest that Microsoft has backed off the C# hard-sell. C++ libraries have been cleaned up, with potential security holes plugged and new features added. Optional language extensions, which Microsoft has submitted for standards consideration, wire .Net-essential capabilities such as garbage collection (automatic deallocation of memory) into Visual C++ 2005. An implementation of the C++ Standard Template Library will provide a portable and transparent wrapper layer around .Net.
But these changes go beyond giving back what Microsoft took away. The new C++ compiler back end generates highly optimized, native executables for Athlon FX, Athlon, Itanium, Opteron, Pentium, Pocket PC, and Xeon. The 64-bit code generators are essential to Windows’ enterprise growth, and Microsoft is wise to position Visual C++ as the flagship language for these performance architectures.
Getting the team together
InfoWorldreaders know how huge the universe outside the developer’s desktop is. Big, interconnected projects that involve engineers, designers, testers, managers, support personnel, and operations staff require some combination of life-cycle and project management tools. That’s where VS Team comes in. It will use design — class modeling, service-oriented application design, and logical infrastructure design — to project a cohesive, individually relevant view of the life cycle to each participant.
Microsoft’s initial release of VS Team will, as one expects from a first release, fall short of meeting vendors’ and customers’ needs. For one thing, the current design does not support the use of multiple VS Team Foundation servers. This will stymie contracted and outsourced projects as well as projects shared on a limited-trust basis with partners. Load distribution is also absent from this first release, a fact that raises questions about redundancy. Participation from remote locations will be managed through typical remote-access technology such as VPN and Windows Terminal Services.
Given these limitations, VS Team’s definition of “enterprise” may not match reality; however, VS Team could meet the needs of the great majority of midsize-to-large development projects, perhaps petering out before the scales tip to huge or gargantuan.
VS Team’s design toolset comprises three elements. Its class-modeling tool is a familiar component found in all commercial-grade IDEs. It maps the methods, encapsulated data, and interfaces used within self-contained project modules. It doesn’t lay out the cohesive solution that will eventually be deployed, which is good. Class modelers are sometimes misused for this broader purpose, a practice that inappropriately saddles developers with the design of the deployment architecture.
The second design tool in VS Team is the service-oriented application designer. Here, a typical project will come to life as a reconfigurable web of components such as .Net assemblies, COM/DCOM (Distributed COM) objects and Web services. The designer defines connections between components, with associated policies governing such details as the selection of interservice communications protocols and the enforcement of security. The interface paradigm is drag, drop, and connect; and the completed design persists in XML for consumption and modification by custom tools.
Finally, VS Team’s logical infrastructure designer reconciles service-oriented design with operational reality. This design interface maps out the deployment topology and identifies conflicts between it and the application’s architecture. For example, contrary to architectural assumptions, there may simply be no network route between one system and another. The basis for the architectural validation is the System Definition Model, which, as part of Microsoft’s Dynamic Systems Initiative, describes the structure of a group of distributed systems.
As elements of class design, SOA (service-oriented architecture), and topology change, the validation flags raised in the various designers change as well. The ideal would be to identify problems as maps are drawn. Instead, validation is performed as an independent step, as when saving a file. The first release of VS Team will also lack the ability to simulate a topology. Without this, the exploration of options for resolving design conflicts won’t be any more efficient than trading e-mails containing designs and advising, “Try this and get back to me.”
Staying in control
The best feature of VS Team Foundation may be its completely rewritten SCCS (source code control system). This replaces the weak Visual SourceSafe, which provided only basic
source-code control to small groups of developers. Microsoft estimates that VS Team Foundation will scale to handle as many as 500 developers per group.
The new SCCS emphasizes scalability and parallel development. Missing are two features relevant to many enterprise projects: remote teams and distributed builds. VS Team Foundation has no specific facility for linking external teams, including consultants and outsourcing firms, into the life cycle as more restricted and closely monitored participants.
One SCCS feature stands out: The ability of a VS Team System client to “shelve” a project. This takes a snapshot of the project and stores that state in SCCS. Shelving allows developers to quickly switch projects, to safely hang up a project until the next workday, or to move from one machine to another, for example, from work to home. When the project is unshelved, the workspace and all associated checked-out code appears in the workspace in its previous state.
The work-item tracking system built into VS Team Foundation resembles a bug-tracking system. Items are placed in topic-oriented queues and assigned to participants. This arrangement is typical, except that Microsoft extends work-item tracking throughout the life cycle, so that nondevelopment groups responsible for operations and technical documentation can also use this functionality. But overall, the tracking system seems a bit loose. It would be better if the system captured some context for each item so that the recipient wouldn’t have to duplicate the submitter’s effort.
VS Team Foundation captures the status of work items, along with knowledge derived from individuals’ use of the tools, in a SQL Server metrics warehouse. The new SQL Reporting Services (code-named “Rosetta”) will provide views into that warehouse. Participants can, within the limitations of privileges, dump their work items to Excel for off-line perusal and modification.
As for testing, VS 2005 will deliver a set of testing tools unprecedented in previous versions. The editor will automatically generate unit tests for everything but C++ code. Code coverage will show the programmer, down to the line of code, what has been tested. Static analysis tools for both .Net managed code and C++ unmanaged code will be in the box. These scan through code looking for potential bugs, deviations from good programming practices, and holes that could be used to compromise the application.
Profiling takes a stopwatch to your code to help you find performance bottlenecks at a fine-grained level. As with code coverage, the profiler shows its results in the VS 2005 editor. Load testing identifies potential bottlenecks and scalability issues in running applications, including anything that uses HTTP for a transport (for example, Web pages and SOAP Web services). Finally, project managers can lay out policy requirements that define minimum testing requirements and acceptable results.
From language improvements to life-cycle management, the new VS Team suite and the VS development environment itself seem almost certain to make Microsoft programmers and their bosses happier. But will these new products sustain Microsoft’s momentum, particularly as it tries to move upscale into more challenging enterprise development environments? As usual, the company seems unlikely to get the new stuff completely right the first time. But salves for the disgruntled and nods to enterprise work modes should make VS 2005 and VS Team the most attractive development products Microsoft has released in a long time.