Actually I'm wondering when is enough, enough? With regards to software, when do you decide that it's good enough to release and the bugs that remain shouldn't stop that? When do you cut off the fixes or changes to the software in order to meet some release deadline?
These are actually, what I'd consider, tough questions. And there is no good answer as each group/company/team needs to decide for itself when is enough, enough. It happens with all software, corporate and shrink wrap, maybe even the personal code that many of us build.
Recently I was in a debate with the SQL Server team about a problem with one of the new features. I don't really want to get into the specifics, but there is a problem in one of the supporting parts of this feature that was filed as a bug. A fix was built, but the bug was closed as "won't fix in RTM", with a note that a fix would come later in a CU/SP and there was a workaround. The team noted that this close to RTM only critical issues could be included in the build so as not to delay things further.
Some people that were in this debate complained that the bug should be fixed or the entire feature dropped. This was a fairly large feature, so it would have substantial impact. People pointed out that this is the reason there's a perception that you should wait until SP1 to deploy new features and that Microsoft was shipping software that wasn't well built.
I disagree with those statements overall, though I think that there are cases they're true. In this situation, however, I didn't think it applied. And I'll give you a situation to think about that's (hopefully) will illustrate my point.
Imagine that you are building a new release of an application for your company. It's an upgrade to some CRM system and you're adding the feature to better group and qualify leads for the salespeople. People estimate this will greatly improve the efficiency of the sales department, and the feature has been a requested one for some time.
However (there's always one, isn't there?)
There's a bug in one of the reports that won't let you get the report by a group of salespeople. Imagine that you have salesman put into groups. You can get an individual salesperson, but not the group, so there's some manual work here to put things together.
Do you delay the release? If a fix is ready, but you're scheduled to release next week and there isn't time to test it, do you deploy the fix or hold it back?
I'd argue that in many cases I'd hold back the fix since testing is important, there's a workaround, and you can plan to deploy this fix, along with others that will definitely come up, in a short time frame. Any major release should expect that changes will be needed in relatively short order and plan for a second point release soon after the first one. Microsoft has agreed to do this with a service pack at six months, and other software developers should do likewise.
I can see both sides, but for non-critical bugs, you have to draw a line somewhere that says we can't include fixes after this date in order to meet a release schedule. All releases are arbitrary, but they exist because whether your are releasing shrink wrap software or corporate applications, some effort goes into coordinating the release. So you have to pick a date.
Delay if something critical is broken, but you can't fix everything. The software will never get done. I'm curious if you agree and when you decide if enough is enough.
Steve Jones
The Voice of the DBA Podcasts
The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
or now on iTunes!
- Windows Media Podcast - 56.8MB WMV
- iPod Video Podcast - 39.6MB MP4
- MP3 Audio Podcast - 8.1MB
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.