A Peek Inside the Microsoft Whidbey Ship Room

In a nondescript conference room at the heart of Microsoft Corp.s campus here, 35 developers sit shoulder to shoulder and prepare for battle.

This is the Visual Studio "ship room," and in minutes it will play host to a raucous, relentless and occasionally personal debate over the bugs remaining in the Visual Studio 2005 application development tools. Developers with underperforming modules try to maintain game faces while being hammered with questions over so-called ship stoppers—bugs that threaten to affect delivery of the product.

"We need this stuff fixed to go to RTM [release to manufacturing]," the meetings moderator barks.

Meanwhile, nearby, a more genteel, but no less critical, session is taking place among 10 developers working on SQL Server 2005. Under the guidance of Paul Flessner, Microsofts senior vice president of server applications, the group sweats the details of testing, training and security in Microsofts much-anticipated database release.

"Building software, I like to say, is a little bit like making sausage," said Tom Rizzo, director of SQL Server product management at Microsoft. "You dont like to see what goes into it, but you like the thing at the end. Customers dont realize the amount of work that actually goes into the process of doing high-quality enterprise software."

The flurry of activity behind the scenes at Microsoft is not without distinct purpose, officials point out. Outwardly, the company has said that while Visual Studio 2005 will deliver a second beta release, SQL Server 2005 will not see a third beta, opting instead for continued CTPs (community technology previews) of the software until it ships by years end.

The shift in beta program plans, along with the furious development campaign within, is part of Microsofts goal to deeply integrate Visual Studio 2005, also known as "Whidbey," with SQL Server 2005, known now as "Yukon," to give developers a seamless experience using the companys development tools to build and deploy database and other applications. Its this bottom-up integration effort that will bring users productivity gains and return on investment, Microsoft officials said. However, both products are late to market, and both are key to future core Microsoft products such as "Longhorn" (Microsofts next major Windows release) and Office 12.

How long will developers wait for Longhorn? Click here to read Peter Coffees view.

The heart of the Microsoft integration strategy lies in the integration of the companys CLR (Common Language Runtime) into the SQL Server database engine, known as SQL CLR. But it doesnt stop there, Microsoft engineers said. According to Flessner and James Hamilton, SQL Server architect at Microsoft, the decision to integrate SQL Server and the Microsoft development tool set was made in late 1999, before SQL Server 2000 shipped.

"This goes back before we shipped SQL 2000," said Hamilton. "We had a very small skunk-works project under way" to improve the tools support for the database.

"The database market never attracted the quality tool support, and so what happens, if you look at Oracle [Corp.] or IBM, the tool support is quite weak," Hamilton said.

Anne Thomas Manes, a Boston-based analyst with Burton Group Inc., agreed that database tools are considered weak. "Its a big win to integrate the Yukon tools with Whidbey," Manes said.

"The DB tools are decent for designing database tables, but theyre awful for developing stored procedures, triggers and user-defined functions," Manes said. "Most DB vendors supply a proprietary stored procedure language [SQL Server Transact-SQL, Oracle PL/SQL, etc.]. More recently, the vendors have added support for standard general-purpose languages—Oracle and [IBMs] DB2 now let you build stored procedures in Java, and Yukon and the next release of DB2 will support .Net."

"The thing youll get [from integration] is the ability to do language-independent development so that where you deploy applications becomes a run-time decision for the IT professional, not a design-time decision for the developer," Flessner said.

Next page: Shared concurrency primitives and memory management.