You bid on a project for a client, telling them it will be done in a month. In a week you tell them you'll demo the project and show them how it works the first week of June. The last week of May you inform them the final project won't be done until July.
But the demo's still on.
Who would run their business this way? One of the world's largest software companies.
Admittedly it's a flawed analogy, but who actually decides to show off their product in a worldwide event when it's not done? Who promises to release a "full-featured beta" at that time? Feb 27, 2008 will be a "SQL Server Announcement Event," not a launch at all. (anyone want to wager on all those features still being in the RTM and working?)
I shouldn't be surprised. I've been doing this a long time, I should expect schedules to slip and know that bugs always crop up, things take longer than expected, and despite everyone's best guess, things won't ship on time. It's happened over and over, and it probably will continue to happen with every product they release. And they want us to buy Software Assurance?
But I feel burned, betrayed, and disgusted. I was fairly upset last July when a "launch event" was announced and then clarified a few days later that this event wasn't intended to mark the release of the product. Instead it's a "marketing event" that's designed to, well, convince you that some day, when Windows 2008 and SQL Server 2008 release, that they're worth upgrading to. Visual Studio is shipping and it's possible that Windows will RTM by the end of February, but with the quiet post last week about SQL Server 2008, we won't see the bits until Q3 (July-Sept). And who knows if they'll come then. Will support for SQL Server 2000 still end in April? I'm fairly confident that they'll ship by Nov 7 (the 3 year anniversary of SQL Server 2005), but only to ensure that those suckers who bought Software Assurance don't file any lawsuits.
At this point, that's bad news. It means there is immense pressure on the developers to get things done. And we know what that pressure does to programmers; it helps them to make mistakes. It helps them to move quicker, think less, gloss over minor things, all in the name of shipping software. And with the quality issues we've seen in their patch testing, this makes me nervous.
I have viewed SQL Server 2008 as a "patched" version of 2005, just as v6.5 polished and stabilized v6.0, and as v2000 stabilized v7.0. However at this point I am concerned with the pressure to deliver a product that is not ready along with issues in testing since SQL Server 2000 SP4. I would not recommend an upgrade if you don't need it. If you must upgrade soon, go with a patched SQL Server 2005, build xxxx, which appears to be stable. If you can wait and have stable servers, I'd think about waiting until SS2K8 SP1 or later.
At this point I don't know what to think, but I'd really recommend that if you have stable servers on SQL Server 2000, don't even mess with 2005 or 2008. Wait until there's a real reason to move forward. That's a great product and it should serve you well for the time being. Maybe by not upgrading, a message will get sent to Microsoft that you don't want to be jerked around by their marketing department. I don't know if it will help, but at least I'm confident of one thing.
Microsoft will never hit that 24-month release cycle.
Steve Jones
The Voice of the DBA Podcasts
The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
or now on iTunes!
- Windows Media Podcast - MB WMV
- iPod Video Podcast - MB MP4
- MP3 Audio Podcast - MB
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.