I thought it was funny/interesting how Microsoft is promising a two year release cycle for SQL Server, not because I think they can't do it, but because in my experience a two year release cycle is forever from the perspective of those developing a product.
The place where I work right now is on a two week release cycle. Two weeks! New code is rolled out to the eBay US site every two weeks (releases are called "trains" in eBay parlance, and a whole gaggle of train-related metaphors proliferates throughout the company because of this). In the off weeks, code that rolled out to the main site two trains ago is rolled out to all the international sites -- the delay allows time for the pages to be translated into all the other languages. Upon hearing about this crazy release cycle, many developers are aghast, and some run away in fear, never to be heard from again. But now that I've been around at eBay for a while, it feels like the right thing to do given the business and technical situations. Of course for any given feature there is a longer release cycle to provide enough time for requirements gathering, coding, testing, documentation, etc..., and the time allocated to develop a feature is almost completely decoupled from the release cycle. There is a process in place to figure out how much time is needed, and then when the feature is ready to be released, you know that you can release it almost immediately and everyone can move on to the next thing.
At my last company, I experienced both the good and the bad of release cycles in a more traditional software development environment. The Blaze Advisor development cycle was modeled around a quarterly release cycle. The company management at the time when Blaze Software was an independent, public company thought it important to have a release at least once a quarter to boost quarterly earnings and keep investors excited about the prospects for the product. The way this was done (in theory, at least) was to dedicate the "Engine/Server" team to one release while the "IDE/Development Tools" team worked on the subsequent release. In actuality, there turned out to be contributions from both teams in most releases, but it did enforce the idea that we should always be working on multiple releases at the same time. The point at which this really didn't work was with "the big release" which was first called version 4.0, then version 4.5, then 5.0, then finally 6.0. This release didn't fit the usual model because it required a rewrite of the underlying repository structure - a piece that affected every part of the product. The way that this release was managed was that some of the developers started working on the underlying code four years before the eventual release. Bits and pieces made their way into the product in the intervening releases, while other parts were kept in a separate branch that couldn't yet be merged into the main product. Some features that were initially designed to be part of the big release were pulled in to respond to market pressures, and to lighten the feature set of the big release itself. There were more than half a dozen significant releases of the product while work was being done on 6.0. If the decision had been made to stop work on the product and get 6.0 out the door as soon as possible, the product would have either been eaten alive by the competition, or, more likely, it would not have survived the internal product politics that occurred with the two mergers that happened in the meantime.
So, what have I learned from all of this? Picking the best software release cycle matters. Props to Microsoft on committing to change -- hope it works out for your developers and your users.
