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
Management of software development projects has always been as much art
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.
"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. We can
actually get some sense of the project's velocity."
-- Etienne Tremblay, Lead Technologist, EDS
"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
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
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
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
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
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 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."
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.