With all the questions about
Right now we're in a bug fixing phase. That means we are working on closing down as many bugs as possible in the product based upon our schedule. A lot of times this is called stabilization. Not very glamorous - but the most important part of a project in my opinion.
During this phase, however, we get to a point where individual teams start wanting to make changes to features that are complete, almost complete or adding new features. This is called a "DCR" or Design Change Request. Here is the fundamental tension that comes up in software management, and I'd assume in most projects. The tension is simply "Do you potentially sacrifice products quality for additional features?"
Like most things the answer is not simple. Often times we get market forces or partner companies requiring changes so our business depends upon a DCR. Other times our customers give us feedback (through usability groups or basic feedback like a blog) and we take that seriously. Sometimes we get major bug fixes or internal partner teams who need us to do work for them. And finally we just have last minute ideas.
Every time a DCR comes up it goes through a process (not glamorous either, but necessary). This process helps us evaluate a basic risk vs. reward scenario.
For example: With the recent Update Rollup 2 release I got a last minute request from one of our PMs to add functionality to down sample DVD playback to 480p when media center is hooked up via component connections. The basic problem we face is that macrovision (the DVD copy protection program) invokes when a DVD is played back at too high a resolution over an analog connection (this doesn't apply to VGA or DVI or HDMI).
The customer impact was clear. Some of our customers will not be able to play DVDs at higher resolution with Media Centers hooked up through component. Seems obvious enough that we should fix the issue -right? Well not necessarily. When the problem and solution were brought to my attention the project was about a month away from shipping. At that point we were essentially done and the test teams were in their final phases of testing. The risk starts going through the roof with every fix you take at that point.
So the question then became - how many people are really using component connections to their TVs and how many of those people are running at higher then 480p and how many of those people will actually watch DVDs through media center? The answer was a pretty small number. So the risk to all our customers for the benefit of just a few didn't seem worthwhile.
In the end I strongly feel that features are less important than stability. I’d rather see us do our core features really well (TV, music, photos, video, etc) then start adding things that a majority of customers my or may not want or need. Not to say that I don’t love features and think they’re important – just not as important as a rock solid product. The two aren’t always related, but whenever you make changes the risk to stability goes up.
All right - interactive part. What would you like to see in
Also would you sacrifice some stability for more features?
See you in the comments....