This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Yet another reason for releasing often Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Dan Fernandez writes about early access to the (due in 2005!) next release of VisualStudio. Simply having these thoughts at all should push you towards a shorter release cycle, IMHO:

Does Microsoft Give Access too Early?
After reading these posts on Whidbey and%A0in thinking about the%A0backlash on Longhorn (too much info too early),%A0it occured to me that maybe its not such a good idea to give the broad developer community early access to code. I'm not saying this because we don't value everyone's opinion, but because it might be dangerous to set%A0such high expectations.%A0 What happens when you see a great feature and you see that it won't be available until the next release?%A0 Some features you like may or may not make%A0Whidbey, it's a technical preview,%A0we really%A0cannot give any guarantee as to what the final product will look like.%A0 As Jay points out, we're even starting to give developers interim builds%A0in a continuous effort%A0to make Microsoft more open to developers.%A0 I would assume this would be a good thing, but%A0there is risk in this approach.%A0The risk is that we over-promise and under-deliver which leads to developers being angry, which is the exact opposite of what we're trying to achieve.

Well, if you release every 6 to 9 months, that ceases to be a problem. We have given developers access to our ongoing builds for quite awhile now - and I'd have to say that it's been overwhelmingly positive - we get bug reports, bug fixes (admittedly, this is easier for us - a Smalltalk system ships with all sources), and we set expectations very concretely - over time, developers have gained a feel for what we can and can't do within one cycle, and they evaluate the builds based on that. It's interesting to see just how many negatives start to flow from having an extended release cycle...