共用方式為


Should Microsoft add features in service packs?

This is an issue that gets debated around the company from time to time, and there are many people on both sides of the fence who feel passionately about it. In Exchange 2000 SP1, we did add a few features. In Exchange 2000 SP2, we added even more (I was the program manager for most of the new features in OWA in SP2). Exchange 2000 SP3 had -- read my lips -- “no new features” (also by that time, the entire team was heads-down working on Exchange 2003).

I have seen varying levels of feedback in Windows and Exchange communities on this issue, such as:

  1. “Yes“: It's OK for applications or operating systems to have features in SPs
  2. “No“: There should never be a feature in any SP of any Microsoft product, it makes the SP buggier
  3. “No“: There should never be a feature in any SP of any Microsoft product, even if the SP is high quality
  4. “It depends“: It's OK for applications to have features in their service packs, but operating systems shouldn't have features in SPs

I'm sure there are many more reasons, but one of the most common ones I've seen discussed is that the quality goes down whenever features are added (#2). With Exchange 2000 SP1 & 2, however, I feel we did a good job of adding features while still achieving a high level of quality, so ever since then I've been wondering if that has helped change any opinions about this issue.

(Site note: Several of us who participate in Exchange communities had a good time forwarding around the mail threads in those communities that happened soon after the E2K SP2 release that went something like this:

Person A: Knowing Microsoft's track record, what should I be aware of when going to Exchange 2000 SP2?
Person B: No problems here! Went without a hitch.
Person C: Likewise, installed it on 5 servers without a single problem. Users didn't even notice it.
Person D: Well, my users noticed it, but only because they noticed the new features in OWA and loved them!
Person E: Ditto.

...etc. OK I'll stop patting myself on the back here ;-)

Not that I mean to imply that no one had any problems at all, but the overall perception I got from looking through the support calls we got and seeing the chatter in the communities was that those SPs were well received, features and all.

So, all that being said, I would like to use this blog to hopefully start a conversation: In your opinion, is it acceptable for Microsoft (and the Exchange group in particular) to add features to service packs? I'm most interested in hearing why you feel the way you do, as well as whether you're talking about Exchange specifically, OS's or all products. Thanks in advance!

Comments

  • Anonymous
    January 21, 2004
    My opinion is no. I'd rather have an even more solid product than the chance of having issues.
  • Anonymous
    January 21, 2004
    First I will say that I love it when features are released "out of band". However, why does a Service Pack have to be the only means by which you deliver new features? With Windows 2003 they've begun to introduce new features by themselves (i.e. iSCSI initiator, Group Policy Manager). Based on comments at the JDP (ehem TAP) sessions they seem committed to continue this practice.

  • Anonymous
    January 21, 2004
    The comment has been removed
  • Anonymous
    January 21, 2004
    The comment has been removed
  • Anonymous
    January 21, 2004
    Thanks everyone who has commented thus far.

    I started writing up a response about feature packs and why it's not a simple answer, but it got so long that I'm going to save it for a new blog entry sometime soon rather than add bloat to my own comments :-)

    Keep 'em coming.
  • Anonymous
    January 22, 2004
    From a security and a stability point of view I say definately not, but (and there always is one), if the feature is something that is causing a large number of customers grief and can be implemented without architectual or significant changes then the benefit of implementing it needs to be weighed up against the security and stability cost of implementing it.
  • Anonymous
    January 22, 2004
    I agree with William

    additional features are OK in an SP but only if its not a major architectural change and only if it's entirely necessary.

    This is the reason that MOC courseware always runs on the vanilla product (No SP's) as they are renowned for adding feature changes and would thus make the courseware wrong.

    Im happy to have new features, just call them a point release rather than an SP..
  • Anonymous
    January 22, 2004
    I thought this question was settled...

    A new feature has the potential to introduce new bugs.

    A service pack is supposed to fix bugs.

    New features should be found in Feature Packs.
    Feature Packs should include Service Packs.

    Service Packs should not include Feature Packs.

    There is no reason that both the FP and SP should not be distributed on the same CD...
  • Anonymous
    January 22, 2004
    I agree with the comment that features should be added out of the normal release cycle and service packs should just fix issues.

    I really wish<a href="http://blogs.officezealot.com/chris">Microsoft Office</a> would follow the windows 2003 pattern. The problem is they come up with all these great ideas in one release and then we have to wait 18 to 24 months to add the few little things that would be helpful that are discovered after the release.

    This is one area where Open Source potentially has Microsoft beat. The old days of monolithic release cycles (every 18 to 24 months) is just not practical for a market that can change every 3 to 6 months.

    Now there are a lot of Add-ins put out by Microsft that are tremendously useful. The problem is that there times where the baked in functionality needs to be expanded to really solve a problem.
  • Anonymous
    January 22, 2004
    It is a shame that MS developers come up with all these internal tools or features AFTER release, and then have to keep them internal, or release them as unsupported tools (Power Toys).
    But I agree Service Packs are not the answer. There should be something like Feature Packs.

    But I can see where this would create quite a support issue (probably what KC was going to write about, no?). You create a much larger cartesian product of permutations of the platform to test every time you want to release a Service Pack or Hotfix. Would Service Packs contain fixes to Feature Packs?
    Instead of having App2K3, App2K3 w/SP1, App2K3 w/SP2 to test against, you now have App2K3, App2K3 w/FP1, App2K3 w/SP1, FP1, App2K3 w/SP2,FP1, etc).

    So, I guess I appreciate why these things often come out as "unsupported" upgrades. But does installing an "unsupported" tool invalidate your support on the base product?
  • Anonymous
    January 22, 2004
    I'm all for new features or the feature pack routine the Windows folks have been following. In fact, I like the latter better. I get a new package to play with, without any other permutations fo problems from bugfixes and what have you/
  • Anonymous
    January 22, 2004
    Well, just call it something different then. But it is in my not so humble opinion not acceptable to wait 2-3 years for a new version of a product with some new features. And even then it is not guaranteed that those features customers have been asking for are really added.
  • Anonymous
    January 23, 2004
    The comment has been removed
  • Anonymous
    January 24, 2004
    Well, Service Packs should be focused on one thing. Fixing problems.

    I think new features should be added by "update packs" rather than "service packs" because new features in service packs can lead to new bugs or features that perhaps are not needed.

    I've seen in some cases systems that are so tight in their integration between different programs that a lot of the OS or Application features are not really used.
  • Anonymous
    January 26, 2004
    The comment has been removed
  • Anonymous
    January 27, 2004
    I'm surprised this issue still exists.

    The issue lies with large enterprises that need to control the features that are introduced. Imagine a corporation that has 200 exchange servers and needs to deploy a critical fix available in a just released SP. In addition to the fix(es), MS decides to introduce a new feature that is visible on everyone's desktop, but for which the enterprise does not have the bandwidth, disk resources, support assitance or training in place. To them, the cost of deploying the SP often includes the cost of planning and deploying new features that they had not planned or budgetted for.

    The solution to this problem is to release SPs with only fixes and if necessary, Sim-ship a Feature Pack or equiv.

    This is a huge disatisfier for large corps.
  • Anonymous
    January 27, 2004
    The comment has been removed