Share via

Feature Packs versus Service Packs: Why isn't it an easy decision?

  • Article

I blogged a while ago about features in service packs. A couple of the comments recommended doing feature packs instead, and since then I've been meaning to blog about the complexities involved in that process, so here it is.

Please note: this post should not be taken as the word on what any product team is doing or planning, I am just attempting to explain why it's not a simple decision to separate features and service packs, and what that entails. Also, part of the below is not specific to the FP-vs-SP debate, but I thought it was useful to describe some of the many things that go into the decisions made about features and releases.

First off, let me restate the original problem: features in service packs. Some customers do not want features in a service pack for various reasons (training of user base on new features, the risk of encountering new bugs as a result of additional code in the feature pack, a stringent approval process needed for any new code deployed in an environment and adding features increases that delay, etc). Others want features available outside of the normal multi-year release schedule (so that they don't have to wait 3 years for a chance at a new feature they want). Also from a software development point of view, there's actually a comparatively small window (or number of windows) in a product release cycle in which new features could be added, so feature requirements need to be specced, coded and tested in those windows. Customers are often surprised when we can't implement a DCR for quite a while after they request it, because of the missed window of opportunity (and of course the ongoing prioritization compared to other work).

The core problem with feature packs is the test matrix. Whenever we release something to the public, it goes through a lot of testing. First off, you have to consider the release order.

Release Order
Say for example we released the RTM (Release To Manufacturing) version of a product. 6 months later, we released SP1 with bugfixes as well as Feature Pack 1 with a few new features. Now our test team has to make sure they test their areas in each installation combination:

  • RTM + SP1

  • RTM + FP1

  • RTM + SP1 + FP1

  • RTM + FP1 + SP1

Then if 6 months later we release SP2 and FP2, it gets even more complex:

  • RTM + SP1 + SP2 + FP1

  • RTM + SP2 + FP1

  • RTM + SP1 + FP2

  • etc

Of course, you can choose to enforce restrictions or designs (have FP2 include all features from FP1, make the installer for FP2 require that SP2 is already installed), but then you also need to make sure you test the scenarios with those restrictions (if you make the FP2 installer check for SP2, have to verify that actually works).

 

Source Files
Ah-ha, but what if a bugfix requires a code change in foo.dll, and a new feature also requires a code change in that file? If the user installs SP1 with the modified foo.dll and then installs FP1, then FP1 would need to include the bugfixes from SP1 as well as the new features. Or you'd have to restrict it so that FP1 can only be installed after SP1 (and FP1 would have to include that fix from SP1 as well).

OS & Version Matrix

And of course, don't forget that you have to test the matrix on every operating system you support. So multiple the above matrices by at least two for Exchange, more for other products. I say “at least“ two because if there is a service pack available for the operating system, you may need to test on the most recent SP as well as the previous one, just to be careful. Or if there is one SP already available and another one that will be available shortly, you may need to test on the beta of that upcoming SP.

What about languages? Ah yes. Exchange 2003 shipped in 9 different languages. Each operating system also ships in a bunch of languages. Some or all of that matrix needs to be tested with every major release.

Coexistence With Previous Versions
This is a biggie: in a product where the machines need to be able to communicate with each other as Exchange servers do, you have to make sure that each new release integrates well with previous releases (not just the full releases but also the service packs). Say we added a feature that adds a new set of properties to a mailbox in a certain release (be that SP or FP or whatever). What happens if you move the user's mailbox from the server that supports that new feature to a server that doesn't?

Build Process

Plus there's the build process. For every release there's a build fork, and each developer needs to have an enlistment to check in fixes or features to that fork, and the build team has to build and verify each interim build of each fork, plus the labs and automated tests need to run against each fork, and so on.

Backup & Restore
If you add a feature that stores a new set of data, you need to take into account how that data will be backed up and restored.

Customizability
Others have suggested including features in service packs but have them off by default or make it an option in the SP install... Making it an option in the SP install means more UI and testing. Having the features off by default might mean design changes (such as supporting not displaying the feature if it's not enabled - for the customers who don't want new features because they don't want to retrain users on new UI). And some customers would still be unhappy with this option.

And more...
I think I covered the big issues above. I hope that this rambling entry explains some of the complexities involved in releasing large software products used by thousands or millions of customers. Thanks to Berg & Alex for their additions to this post.