On Microsoft CTPs and long release cycles

Microsoft's CTP program can result in higher quality, more usable, and more secure products- but when badly managed, it can also cause confusion and fuel doubt.

Contributions to this Editorial come from Adam Machanic, an independent database software consultant based in Boston, Massachusetts. He has implemented SQL Server solutions for a variety of high-availability OLTP and large-scale data warehouse applications, and also specializes in .NET data access layer performance optimization. Adam is co-author of Pro SQL Server 2005 and regularly speaks at user groups and community events throughout New England.

On March 14, Microsoft extended its Community Technology Preview (CTP) program to include service packs, with its CTP release of SQL Server 2005 SP1 (the final SP1 is due this month).

The big idea behind the CTP scheme is to remove the usual secrecy and non-disclosure that surrounds Microsoft’s beta programs. Instead of a hidden process that only the “important” users can be involved in, the CTP program gives a voice to everyone who wants one. Instead of keeping the bugs and problems in a private area, the CTP program throws open the doors, creating an almost-transparent escalation process via Microsoft’s Product Feedback Center – a system that anyone can log into and post a bug about a Microsoft product, including a CTP.

The CTP scheme is viewed by most as a good thing. Certainly, the company has been criticized in the past for failing to address bugs, especially those that have to do with security issues. As Adam Machanic, SQL Server MVP, puts it:

“As a SQL Server user, I feel less frustrated by bugs when I know that I can report them into a system and that they will be validated by someone at Microsoft. It is also comforting to be able to sift through issues that others have found, seeing not only problems that I should watch out for, but also the workarounds suggested by the Microsoft employees who have responded to the bug reports.

I feel that the CTP program is a step in the right direction for Microsoft. The CTPs, and especially the Product Feedback Center, make it nearly impossible for Microsoft to ignore the major issues-and certainly impossible for Microsoft to pretend that they don’t exist.”

While CTP releases undoubtedly provide an excellent feedback cycle, a certain amount of mystery, confusion and inevitable speculation still surrounds them, felt most acutely when Microsoft “moves the goalposts”. In spite of the “quality-driven rather than calendar-driven” rationales coming from MS-central, the inevitable conclusion drawn by many from a CTP move/slip is that the product will be delayed (again). Visual Studio and .NET got beta2s, with attendant go-live licenses, in April 05. However, after a beta2 in late 2004, it was CTPs all the way for SQL Server, right up to final release, and it created an atmosphere of doubt. Few were short of an opinion as to when the true final release date would arrive, with many skeptical that it would hold in 2005. Of course, hold it did (just) although not with all its intended features intact – database mirroring, and the slim-line Management Studio Express, being belatedly welcomed into the fold with SP1.

Microsoft really does need to manage this CTP process carefully. A CTP is more “conveniently movable” than a full beta, and it’s small wonder that a CTP slip provokes rumor and gossip, when viewed in light of the seemingly endless Windows Vista saga.

Speculation has been rife for months – years even – as to when the epic Longhorn-Vista journey will finally end, and has been pretty much non-stop since MS replaced a November 05 CTP with a December one (studiously avoiding the term “delay”) and then, in March 06, finally conceded that the full Vista launch would be delayed till January 07.

A few weeks ago, an article made it onto digg.com suggesting that the reason for the delay was that 60% of Windows Vista code had to be rewritten. Although barely credible, and flatly denied by Microsoft, the ensuing debate is pretty instructive as to intensity of passion that surrounds these matters. A blogger at mini-Microsoft has gone so far as to suggest that the solution is to fire the MS leadership immediately.

Can Microsoft really afford any more of these marathon releases? I think everyone appreciates the shear magnitude of projects such as SQL Server 2005 and Vista, and are generally tolerant of MS taking their time to get these big products right:

 

“As a person who makes my entire living working with SQL Server and applications that use SQL Server as a backend, I’m quite interested in the overall quality of the product, and am certainly willing to wait if it means better output from Microsoft. Should the quality of the product decrease, I will either have to put in more time to figure out how to work around the issues, or learn some other product to make money working with.” -AM.

To the average developer, these delays are probably no big deal, maybe even comforting. But others, such as PC vendors, suffer in their wake. For ISVs, these mammoth releases represent something of a double-edged sword. One the one hand they have time to make sure their software works well with the current release and they have stability, which is particularly important in areas such as financial services. One the other hand, some of the smaller ISVs find themselves staring up a very shear cliff-face, as they strive to make their tools compatible for their customers who do upgrade quickly.

Even Microsoft, invulnerable as it seems, and short of the odd few million as it is not, must have the odd nervous moment about the ultimate return on these huge, drawn out investments.

With careful and open management, maybe the CTP program really does represent Microsoft’s way out of these travails, and its route back to the 2-3 year release cycle. The Microsoft community is passionate and faithful. Get their feedback, drive up quality, usability, and security, and focus relentlessly on those features that truly matter to people…and then deliver them on time (or at least close). Grand visions and eye-popping new features are good and necessary but when they are subsequently pulled (see WinFS, for example) it shakes people’s faith that the final product will be truly worth the long wait.

For sure, it won’t be another five years before we see the next major version of SQL Server. Call me crazy, but when Paul Flessner talks of 24-36 month release schedules from here in, I am prepared to believe him. The SQL Sever 2008 speculation starts here.