Windows Confidential: The feature battle
When you’re redesigning a feature from scratch, every old feature becomes a new feature request.
Raymond Chen
Every so often, a component of the UI will get a major overhaul. When that happens, every other feature starts out at -100 points—even features that already existed in the old version.
This concept of -100 points was originally explained by Eric Gunnerson when discussing why the C# language has some features, but not others. The principle generally applies to any product design process. Every idea for a feature starts out with an imaginary deficit of -100 points. That means it has to demonstrate a significant net-positive effect on the product as a whole in order to emerge as being truly worthy of consideration.
A feature that provides a shortcut to something that’s already fairly easy to do doesn’t earn very many points and will fail to reach positive territory. A feature that benefits only a small percentage of users will also fail to earn enough points to overcome its initial deficit. A feature that seems rather simple on its own but creates additional complexity elsewhere may end up being a net negative. This is a bad enough situation even without the additional penalty of starting with a negative “score.”
Start me up
The Start menu in Windows 95 replaced the old Program Manager from Windows 3.1. The Program Manager had an option called Save Settings on Exit. If you unchecked it, any changes you made to program groups would be discarded when you logged off. There was no corresponding feature in Windows 95.
When feature-removal happens, there’s often a huge outcry from people who were attached to that old feature from the old design. They say: “How dare you remove the X feature from the redesigned Frimble Framble?” This question is backward, however. The feature wasn’t removed from the redesigned Frimble Framble. The feature never existed in the redesigned Frimble Framble. So it’s not that the feature was removed—it’s that the feature wasn’t added.
The decision to kick old code to the curb and start from scratch is presumably not done just for laughs. The old design may no longer be suitable for modern workloads. A design that works when there are a few thousand records may not work as well when there are millions of records. The old design may simply be outmoded. Instead of trying to build a new version on top of the old one, the designers decided to go with a fresh start.
All features from the previous design go into a feature battle against all the features from the new design. Most will survive because they’re basic features any design would have to take into account. They easily overcome the 100-point deficit that all features have at the beginning of the process.
On the other hand, more esoteric or lesser-used features might not make it into the final version. Others may not survive not for lack of points, but for lack of resources. Suppose an old design had 100 features. Suppose you have enough resources to give the new version 100 features. If every feature from the old design were carried over to the new design, the result would be a new design completely identical to the old design. If that’s the case, why redesign it in the first place?
The conflict between old features and new ones can be direct. Old feature X can be in direct conflict with new feature Y. If you choose to keep X, then you can’t efficiently do Y, and vice versa. For example, feature X might become infeasible once the record count exceeds a few hundred thousand. Alternatively, a feature may fail to make it into a new version not because it lost the feature battle against another feature, but because the people creating the new version weren’t even aware of the old feature in the first place.
In many cases, old features are lost with much reluctance. “Yes, we really wished we could’ve added feature X, and it was a really painful decision to leave it out,” the team says. “We were hoping to be able to sneak it in, but the estimated cost for adding the feature came out to around 10 days, and we simply don’t have that much time in our schedule. Sorry.”
As with any project, reality prevents you from doing everything you’d like to do. Part of the job of engineering is making trade-offs among the things you have to do to decide which features will be implemented and which features have to be left behind.
.jpg "Raymond Chen")
Raymond Chen’s Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. The information provided here is for informational purposes only and is not intended as a substitute for professional legal advice.