In-Depth

Taking the Mystery out of Software Development

Some partners are restructuring their businesses around Visual Studio 2005 Team System. Should you do the same?

• By Scott Bekker
• May 01, 2006

Keeping on top of a software project requires several squishy people skills. Managers must call or talk to their developers constantly to determine the state of each person's aspect of the project. There's also the matter of discerning that one developer's "almost finished" means "barely started" while another's self-imposed deadline of Friday can be taken to the bank.

Then there's the instinct about software bugs that good software development managers hone with experience. This is the ability to know by examining a bug whether it's the type of problem that will take one developer 20 minutes to fix or the type of black hole that will consume every developer on the team and push back the whole project by two months.

Until recently, Microsoft's Visual Studio integrated development environment didn't concern itself with software development project management. The tool was designed to maximize each individual developer's productivity, and by most accounts had done the job pretty well.

While often viewed as a software development tool for enterprise customers, Visual Studio is the lifeblood of many Microsoft partners, from independent software developers to custom solution providers, either in a five-person local firm or at a global systems integrator. Even more so than in enterprise development shops, partners whose business and bottom line depend on the efficiency and effectiveness of their team development process may have the most to gain from the new changes to Visual Studio.

Given Visual Studio's prominence, any new capability is vitally important for the Microsoft partner community to understand and exploit. Microsoft's push to enable new capabilities for project teams -- called the Visual Studio Team System -- is an improvement worthy of evaluation. Microsoft began rolling out the capabilities with the November launch of Visual Studio 2005 and is wrapping up the first version now as Visual Studio Team Foundation Server becomes generally available.

The example of EDS Corp., one of Microsoft's largest global systems integrators and a Technology Adopter Partner working with the team elements of Visual Studio ahead of their general release, shows some of the ways partners can leverage the new capabilities.

"We've run quite a few projects worldwide using the new Team Suite capabilities," says Aaron Kowall, chief technologist for the Plano, Texas-based company. What EDS is learning may help partners across the spectrum figure out how to get the most from the new capabilities.

A Team-Oriented Development Environment
Visual Studio has long been the domain of individual developers. The 2005 version brings many productivity improvements along familiar lines. There's integration of the latest enhancements of the .NET language, tight coupling with data-tier improvements in SQL Server 2005, new tools for Microsoft Office and consolidated Windows mobile development platforms.

But there's another dimension to the product this time around. Visual Studio 2005 adds the Team System, which is all about developers working together and getting projects finished on time and on budget. There are tools for tracking projects, figuring out how much of the code has been tested, for measuring the seriousness of bugs, for analyzing the productivity of the team, for determining how much coding is actually finished and for updating business managers and other non-developers on project progress.

Specifically, all this functionality is delivered in a series of new editions and elements. Visual Studio .NET 2003 brought job roles to the suite with the Enterprise Architect, Enterprise Developer and Professional editions. The 2005 version ties the roles together and adds some new ones. There are the new Team Editions in three versions: one each for Software Architects, Software Developers and Software Testers. Additionally there's a Team Test Load Agent. But the core of the team suite is a server product, Team Foundation Server, which pulls all the disparate developers and efforts together.

The individual IDEs connect to the Team Foundation Server, which acts as a data warehouse and report generator. By tracking various data culled automatically from various project team members' work, the server is able to provide development-specific progress reports on the metrics cited above. Such information is also revealed to non-development managers through a Windows SharePoint Services portal site and via a client called Team Explorer that can be used independently of the full version of Visual Studio.

Developer collaboration and project tracking aren't new concepts. Previously, it's been possible to tie together projects through third-party software, or to use Microsoft Project Server to keep tabs. But in the past, such approaches often required developers to stop what they were doing and switch to another application to update their status. This interruption often led to patchy participation and inconsistent results. Project-tracking systems that required developers to estimate their own progress, meanwhile, required the same level of manager interpretation as the old-fashioned phone call or face-to-face meeting. What does 50 percent done mean for a given developer?

That history makes Microsoft's decision to build the capability into the core IDE, and to have the reports be automatic based on source-code checks, very important. Because it's a given that Microsoft partners doing software development and custom application work will run Visual Studio, it's a key step in helping partners take the mystery out of their software development progress estimates and timelines.

Prashant Sridharan, group product manager for Visual Studio at Microsoft, says the Team System in Visual Studio 2005 was designed very much with Microsoft partners in mind, often more so than enterprise customers. "The most [significant] inroads we could make were all about making partners more productive," Sridharan says. "There is no question that the largest amount of software development teams resides in partner organizations."

Team System = Good Timing for EDS
When EDS looked to reshape its global custom software solution operations, the company found Visual Studio 2005 could help streamline the process.
In the past, EDS developers were part of regional divisions -- a geographically based division would have its own sales, consulting and development personnel who would work on projects locally. But simultaneous with the Nov. 21 launch of Visual Studio 2005, EDS launched nine technology centers dedicated to .NET development. Four of the centers are in North America, with others in the United Kingdom, Egypt, New Zealand, India and Brazil.

By centralizing .NET development in the centers, EDS believes the development teams will become even more skilled through specialization, and the company will have a development organization that can work around the clock for customers.

While the company has plans to use the model for J2EE and legacy development, .NET is the first step and the team capabilities of Visual Studio helped make the platform a logical first choice.

"We're separating our industry experts and front-line analysts from our back-end coding and testing activities," EDS' Kowall says. "The increased level of collaboration in Visual Studio 2005 fits that model quite well."

How EDS Uses Team System
The benefits of the Team System come in several areas. For one, EDS is able to use the collaboration capabilities enabled by the server to support the remote requirements of its new globally distributed .NET development centers.

Etienne Tremblay, lead technologist for EDS, says the company has other ways to enable long-distance collaboration, but that Team Foundation Server has made it easier and quicker to implement the kind of global operation EDS wants to establish.

What's more important than the availability of the information is the usefulness of the metrics that Visual Studio is now revealing for EDS. According to Tremblay: "Having better information is leading to better decisions. It is just a far more productive development environment."

One area where EDS is getting more information involves the rate at which new bugs are being created. "In a lot of projects, you have a project manager with a task list that goes around. There are always going to be 20 things on the list," Tremblay says. "Now we can see the number of tasks completed, period over period. We can actually get some sense of the project's velocity. A lot of this is baked into the metrics."

"Because all of this is being housed in the data warehouse with Team Foundation Server, we can actually do some reporting. Are we producing more defects per line, or are we actually generating additional bugs?" Tremblay says.

Tremblay has found that EDS project managers are indeed now less reliant on verbal assurances from staffers about their progress. "Historically, project management had been reliant on the best information that their staff is telling them as per progress. By using the metrics within the toolset, it's much more transparent to actually see where the project stands," he notes. He's also found that the integration within Visual Studio makes the progress tools work. "It's much more a part of the normal part of development, rather than in a work-tracking program."

In developing the Team System, Microsoft aimed to make bug tracking inherent, too. "A lot of times in the development process, things kind of fall on the floor," Microsoft's Sridharan says. "With Team System, because it's available and accessible for the vast majority of developers, the bug tracking system is more palatable and will give partners a great deal of accountability in making sure bugs are resolved."

EDS is taking advantage of a number of the bug testing and metrics provided by the Team System. Especially helpful are metrics on code coverage. "When you do unit testing, your unit test calls your code and tries to hit all the code paths. The code coverage is the metric that tells you how much of your code was actually covered by your unit tests. If your code coverage is 50 percent, that means you're missing some unit tests," Tremblay explains. "Now all these metrics get generated by the server. You may have 100 unit tests, but it only covers about 30 percent of your code. In the past, most companies used third-party tools to check code coverage, or it just wasn't being done."

In Tremblay's experience, the new transparency goes beyond the development project manager. It's now easier to pass metrics up to the consultants and business managers who may not be intimately familiar with the development process. That gives the opportunity for the customer-facing specialists to communicate more accurately with customers about how close the project is to being finished.

EDS was heavily involved in development of Team System. Tremblay feels it's a very good first effort, but he says there are areas that could be improved for version two. "One of the shortcomings of Team Suite is that there is no user interface testing. You can do automated tests to do almost everything -- not Windows forms, but you can do Web forms. [We] have someone who manually tests the Windows UI."

What's Next
Enhancements to the Team System are coming. Although Visual Studio 2005 is barely out the door, Microsoft has two more versions of Visual Studio on the drawing board.

Customer supportability is one area in the upcoming "Orcas" release that could hold more promise for partners. The Dynamic Systems Initiative is Microsoft's push for complete application lifecycle management across its systems. One of the goals there is to make it easier for developers to create applications with the IT department and end users in mind. Rather than throwing finished apps at the IT department and letting IT administrators figure out how to support the applications, DSI is partly about automating the creation of documentation and internal metrics that can give IT a clear understanding of how to deploy, support and scale customized applications. While this policy is frequently explained by Microsoft in terms of a process between developers and IT departments within the enterprise, it could have implications for helping partners deliver more supportable applications to their customers. Microsoft intends to build some of the DSI work into Orcas, which is currently billed as more than a year away.