LinkedIn | FaceBook | Twitter
In an earlier post I mentioned how we create the initial ideas for our software features. This may be a different process than you've seen at other software shops. Another big difference in the way the SQL Server organization does things is how we implement those ideas in the coding process. This has been talked about elsewhere, but as far as I've found not in a continuous narrative. So here we go.
You may be familiar with Agile, CMMI and other software development processes. Depending on what we're developing, Microsoft uses these and many other methodologies to put code to screen. But as an overriding paradigm SQL Server is using something called "Sustained Engineering". Let me explain what that means.
In many software shops, you get your ideas for the "next release" of the product. You decide on a dozen or so new features, and then you add in fixes and enhancements to the features in the current product to the list. Then you start executing against that list for development and testing. Once you have the product close to completion, you release it as a "Beta" to a few companies you know will test it and provide feeback. Once the product is out of Beta, you fix the bugs you've found, and then you finalize documention and release.
While this works pretty well, it does have some drawbacks. For one, if features begin to take large dependencies on each other, you run the risk of having major blocks in the process and taking longer to release. Also, you can't get your users in on the process early - everything sort of gets done at once, and then you serialize your process while the users take a very short period of time to test it out for the edge cases your internal testing doesn't catch. If your customers tell you they don't like a feature, it's a lot of work to rip it out. Also, you wait on documentation. And, if you do have those long delays, you still can't release early if the market (your competition) demands it. It's kind of an all-or-nothing approach. If things get difficult, this can be really painful to live through.
In Sustained Engineering, after we determine the feature, fix and enhancement list, we create a matrix of those features and fixes, putting them into regular "Customer Technical Previews", or CTP's on a schedule. These are kind of our "Beta" product releases. The difference is that each CTP is a full release - ready to go, with all fixes, enhancements, the installer and upgrade code, documentation, everything. Customers start using that software and provide feedback starting with the first major batch of features. We then start over with the next batch of features, enhancement and fixes for the next CTP, all the way out to release. The final release then just becomes fit and finish work, and any design changes we need based on customer feedback. In effect we're releasing the product at every CTP. And we invite everyone - not just a few companies - to participate and give feedback.
The advantages of this approach are twofold: We get early, rich feedback along the way, and we can release very quickly. At any point we can cut or add a feature as time and resources permit and then release production-ready code. No more major changes to a feature the customers have been testing and planning on. More stability in the product, and fewer bugs at the end. Documentation releases with the product at CTP, so people have a chance to understand the product and use it.
Is this a perfect method? No. There are ramp-up and ramp-down costs, and it really makes you think about what you're going to do. But so far it seems to be working - we're on track, and on target.
PingBack from http://msdnrss.thecoderblogs.com/2007/09/12/sustained-engineering-process/