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.