Microsoft Pays Visual Studio Debt

 
 
By Darryl K. Taft  |  Posted 2007-11-19
 
 
 

REDMOND, Wash.—When Microsoft set out to build the latest version of its application development toolset, the companys developer division leaders decided to first pay down some debt.

Microsoft released Visual Studio 2008 to manufacturing on Nov. 19, but two years ago this month, S. "Soma" Somasegar, corporate vice president of Microsofts Developer Division, decided the best way to move ahead was to take a step back. Somasegar said Microsoft needed to get more "intentional" about its engineering if the company was going to be able to upgrade its tool set every two years as planned.

Indeed, Somasegar said he had learned a lot from the companys experience with Visual Studio 2005.

"When we started Visual Studio 2005, our internal aspirations were to ship it in 24 months, but we shipped it 39 months later," Somasegar told eWEEK during a visit to Microsoft headquarters here. "That was a little longer than we wanted it to be. When we started Visual Studio 2008, our internal aspirations were to get done with the product by the end of calendar year 2007."

Somasegar said Microsoft had accumulated a lot of "debt" in building Visual Studio 2005, codenamed Whidbey, and entering the development cycle for Visual Studio 2008, codenamed Orcas. So in November of 2005, Somasegar ordered a halt to all engineering and directed the development team to focus on catching up on testing and clearing out bugs.

The testing period lasted four months, from November 2005 to March 2006, and was known as MQ or Milestone Quality.

"MQ was our first step in moving toward an intentional engineering model," said Carol Grojean, Microsofts Visual Studio 2008 program manager. "Soma, to his credit, shut down engineering, and MQ was very much a grassroots effort."

Click here to read more about Visual Studio 2008.

Somasegar said the four-month period was set aside "not for building new features, it was going to be an engineering investment where the whole team was focused on two things: getting clean and staying clean."

One of the areas Microsoft had fallen behind on was test automation, he said. When Microsoft shipped Whidbey, the company had anywhere from 30 percent to 80 percent code coverage via its test automation, Somasegar said. "So this time we said we wanted to take the four months to catch up on test automation, so that we could start with a clean slate," he said.

Also, as part of staying clean, Somasegar said he wanted to make sure the development team did not accumulate further debt.

"So along the way one of the things we used to measure was the number of bugs that we needed to fix before we could ship a product," Somasegar said. "At the peak of the development process for Visual Studio 2005, I remember days where we had 32,000 bugs in our bug database that we had to fix before we could ship the product. For Visual Studio 2008, at the peak we had about 5,000 bugs. So it was an order of magnitude change."

Part of the reason for change was the paying down of debt Somasegar ordered. Another part was his decision to move from the concept of being "code complete" to being "feature complete" and assigning small teams of programmers and testers to work together as "feature teams" responsible for the completion of specific features.

The reason the bug count dropped "was because if a feature crew got beyond 40 or 50 bugs as a bug backlog, we would tell them to stop and go fix some bugs before they continued," Somasegar said.

Microsoft also instituted a notion of quality gates. Quality gates are a set of tools that developers must use to check the quality of their code during the development process. "There are N number of things you need to do, which we call the quality gates, before you can check in your source code into the main build," Somasegar said. These include things like having to run static code analysis tools, running test automation, having test automation deliver a particular level of code coverage and so forth, he said. There were 17 quality gates.

Moreover, Microsofts policy of using its own technology to build new technology—what company officials refer to as eating their own dog food or "dogfooding"—played into the development of Visual Studio 2008. The Orcas development team used Microsoft Team Foundation Server (TFS), a component of the Visual Studio Team System family, as its repository and configuration management system.

"Were huge believers in self-hosting and we used Team Foundation Server," Somasegar said. "So you can say Visual Studio 2008 was built using Visual Studio 2008. And the biggest benefit of using TFS was transparency and insight into the status of the project at any given point in time." Indeed, using TFS is like pregnancy and child birth with tools like sonograms "where you can monitor progress of the baby almost from day one," he said.

TFS also includes a feature directory, where all features were listed and developers could go in and see where each feature stood in terms of completeness. And although Whidbey had about 400 features, Orcas had nearly 600, said Tony Goodhew, a Microsoft product manager involved with the planning and shipping of Visual Studio 2008.

Somasegar said the investment of those four months to focus on quality and the other changes have set Microsoft up with a clean slate to focus on Visual Studio 10, the next version of the product.

"In hindsight it was one of the best things that weve done as a division," Somasegar said.

Grojean said the Orcas team won an internal engineering award from Microsoft Chairman Bill Gates for its MQ effort.

"Well be debt free for the next release," she said.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.

Rocket Fuel