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 meeting's 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, Microsoft's senior vice president of server applications, the group sweats the details of testing, training and security in Microsoft's 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 don't like to see what goes into it, but you like the thing at the end. Customers don't 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 year's end.

The shift in beta program plans, along with the furious development campaign within, is part of Microsoft's 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 company's development tools to build and deploy database and other applications. It's 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" (Microsoft's next major Windows release) and Office 12.

How long will developers wait for Longhorn? Click here to read Peter Coffee's view.

The heart of the Microsoft integration strategy lies in the integration of the company's CLR (Common Language Runtime) into the SQL Server database engine, known as SQL CLR. But it doesn't 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. "It's a big win to integrate the Yukon tools with Whidbey," Manes said.

"The DB tools are decent for designing database tables, but they're 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 [IBM's] DB2 now let you build stored procedures in Java, and Yukon and the next release of DB2 will support .Net."

"The thing you'll 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.