How We Developed SQL2K8
I've been wanting to write this blog entry for some time now and just have never found the time to sit down and do it. Well today seem like as good a day as any to do it. I'm not focusing on the entire SQL server development process but rather give you some insight in to what we did in the manageability team. This is more philosophical for high-level process then meat and potatoes.
After we shipped SQL2K5 we sat down and brainstormed things we could do for the next release. As you can imagine the list was amazingly long. There was one major theme that we wanted to adhere to: make it easier to manage SQL Server. You can say this a number of different ways but they all mean the same thing. Honestly that was the easy part the hard part was deciding of all the things we could do what would have the biggest bang for the buck. We did some detailed customer analysis to come up with three big bets. Those turned out to be Policy-based Management, Data Collector, and Intellisense. There were also a number of smaller areas we knew we wanted to invest in. Finally, we knew there were several things with the tools that we wanted to fix.
As anyone developing software knows you can't do everything at once. So we had to choose where to start. There are a number of different software development methodologies and processes. One thing that is common among almost all of them is to start with the riskest areas first. This meant we had to start on the three big bets.
In some respects this was an easy decision and in others it was one I struggled with for the entire release. I knew we would come under criticism from our most vocal customers and users. They were expecting us to focus our efforts on what was fundamentally broken in the previous release. And here we were working on cool shiny new toys with a promise that we would get to the other things.
Some interpreted this as us not caring about what was broken. This couldn't have been farther from the truth. But we knew two things: first, if we did not innovate in the area of manageability we would fall behind Oracle. Second, if we didn't start on the high risk items first there would be little chance they would make the release. See new features require time to bake and they need a lot more user feedback than making improvements to existing functionality. This meant we needed the longest runway possible.
This left us with a single choice: start with a shiny new toys. It is really just now, roughly 15 months after starting work on SQL2K8 that we're addressing issues with existing functionality.
This strategy was somewhat of a gamble and we won't know for sure if it paid off until several months after the release. One of the tests will be to answer the question: " will we use the same model again?" Right now I can't answer that question. Once we start to formulate the areas of investment for the next release will have a better idea of what model to employ.
Comments
Anonymous
January 28, 2008
La vieAnonymous
January 28, 2008
I have to say that this is somewhat disappointing to read. The timing of this post and the announcement of the SQL 2008 delay is no coincidence. On the one hand, I'm quite happy to see that it's delayed, and not being pushed out the door. On the other hand, long standing 'behavior by design' issues stand open, and carry forth to SQL 2008. For example, the performance of management studio is just not on par with what we had in SQL 2000 - and isn't materially better in SQL 2008!Anonymous
January 29, 2008
The comment has been removedAnonymous
January 29, 2008
Ctrl-B is something we're still considering. You can track it here; http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=276081Anonymous
January 29, 2008
Perhaps a more balanced approach would be more appreciated by customers. Deliver some of the features on a more regular basis through out-of-band delivery mechanisms and service packs. Appreciate that customers do not want to wait 3 years to have something fixed, and for many issues that may not make it in the next build, it might mean a 6 year wait. So, I would recommend an approach that would deliver more frequent releases to customers and using alternate delivery mechanisms. For example, perhaps some of the management tools could have been delivered as a side product to helping manage a SQL 2005 installation, while SQL 2008 focuses on some of the fundamental changes in the database interior.Anonymous
January 29, 2008
In SQL2K5 SP2 we fixed over 700 bugs. I hesitate to give this number but I think it's important to recognize that SPs are already being fully leveraged for getting fixes to customers as quickly as possible.Anonymous
January 30, 2008
Dan, Thanks for the note and I can certainly understand you working on the big features. We certainly don't want to fall behind Oracle, but it is disheartening to not have a good focus on fixing the last product at the same time. It's not like you don't have the resources (http://www.microsoft.com/msft/earnings/FY08/earn_rel_q2_08.mspx). I think the Resource governor and DMF is fantastic and you've done a great job. Kuds to the team. Haven't worked with Intellisense or DC enough, but they are good steps. However, SP2 is broken. It has issues, some of which were addresses in cumulative releases, some not. SP3 needs to be released that rolls up changes.Anonymous
January 30, 2008
Dan Jones provides some interesting insight into the development process of SQL Server 2008. SQL Customer Advisory Team releases a partition management utility on CodePlex. The storage engine team con ...Anonymous
January 30, 2008
I appreciate your transparency in letting us know the general track you took when building SQL 2008. Unlike some of the previous commenters, I do see the benefit of the strategy you took ... as long as your team does get around to fixing those critical issues that SQL 2005 admins and developers have. Part of me wishes that Reporting Services was one of the "big topics", but I can't disagree with the areas you chose to develop first. Good luck with the release.Anonymous
January 30, 2008
I have mostly worked for ISV in the past, as often the software has to work on both Oracle and SQL Server we can not make use of match that in not in Sql Server 2000 (as there is nothing to match it in oracle) therefore our customers have no reason to upgrade to later versions of SQL server. Hence Microsoft does not get the profit from the updates. You could change this by adding a few features to Sql Server that better match Oracle and therefore give us a VERY good reason to only support the latest version of SqlServer. • Being able to defer the checking of a constraint until the transaction commits. This makes writing data updating code so match easer can is already supported on oracle. • Allowing ALL additions of Sql Server to use index views, otherwise we can not make use of them, as some of our customers will only use the low end additions (they don’t have match data). • Letting a stored proc return DataReaders as output parms, so that calling the stored proc is more like calling a oracle stored proc. • Provide support for sequences, so that key generation can be done in the same way as on Oracle. • Making it as easy to write SQL that returns trees as it is Oracle, e.g. support “Connected By” etc as well as your more power system.Anonymous
February 05, 2008
Dan Thanks for the info, but I am very frustrated with the lack of fixing issues in SQL 2008. One thing I was hoping is to get a better Management Studio. When you think about the SOHO market, Management Studio is a disappointing tool, almost useless. I miss SQL 2000 Enterprise Manager. I don't really bother with new shiny toys, I want like many basic features working well. SQL 2008 look more like a big service pack rather than a new product. After all when you look at Visual Studio, they got it wrong with the 2005 version and they get it right with the 2008 version. So why not the same with SQL 2008?Anonymous
February 05, 2008
The comment has been removed