“Scope Creep”, also known as “Feature Creep” and “Creeping Featuritis“, is the tendency of development teams to constantly find opportunities to add new features to a product. It is widely considered to be deadly: It’s obviously destructive to project schedules, but adding new features also has an enormous impact on much more than just the time and cost of the project.
Apple has recently posted an excellent page on their developer resource site that sums up these larger costs of Scope Creep quite elegantly and succintly. It’s worth a read if only to have these talking points handy for your future meetings:
When making design decisions regarding features in your application, it’s important to weigh the costs, not all of which are financial, against the potential benefits. Every time you add a feature to your application, the following things can happen:
- Your application gets larger.
- Your application gets slower.
- Your application’s human interface becomes more complex.
- You spend time developing new features rather than refining existing features.
- Your application’s documentation and help become more extensive.
- You run the risk of introducing changes that could adversely affect existing features.
- You increase the time required to validate the behavior of your application.
Of course, the part I’m most interested in is the third bullet about complicating the user interface. Where a feature is supposed to help some users, it may make life more complicated for far more users.
Too Many Cooks Should Stay Out of the Kitchen
Some of the best arguments against creeping featurism have been made by Havoc Pennington in his excellent 2002 essay “Free software and good user interfaces“, which focuses on the open-source community’s particular vulnerability to featuritis. You see, because open-source projects do not have finite time and budgets, they are especially succeptible to contributors’ adding new features without end. Mozilla, Havoc notes, has hundreds of features that aren’t even visible in the UI (they’re only reachable by command line). In open-source development, these new features almost always come out as “user preferences”, tabs and command-line switches to endlessly customize an app to each individual developer’s tastes.
These are all of the tabs within the Tabbrowser Extension preferences dialog. There are probably thousands of ways of configuring this.
(Click for full size view)
My favorite example of preferences craziness is Firefox’s “Tabbrowser Extension“. I love tabbed browsing, and I love to customize Firefox. But this Tabbrowser Extension is a bloated mess (you can see all the prefs over there on the right — click for a full size view). I literally don’t know what to do with these settings because there are far too many overlapping and contradictory preferences. Even the author himself admits that the app is a mess. Here’s what he says on his project homepage:
Note: This extension strongly unrecommended. Tab Mix is recommended instead of this, because it is stable, light, and it covers most useful features of this.
This is an extension for extending operations of tabbed browsing, e.g., tabs become re-ordable by drag and drop, show tabs like a tree, and so on. Add-on Modules are available if you want more features.
If you think this is too heavy and too gigantic having many needless features, see a thread in MozillaZine: Rebuilding TBE’s featureset with other plugins. There are many tiny extensions which provide each feature of TBE’s.
If you wish to eliminate tabbed browsing features, I recommend you to try the Tab Killer.
Havoc outlines the following specific problems with having too many preferences:
- Too many preferences means you can’t find any of them.
- Preferences really substantively damage QA and testing.
- Preferences make integration and good UI difficult.
- Preferences keep people from fixing real bugs.
- Preferences can confuse many users.
Introducing the Scope Creep
The “Scope Creep”, seen above, is a creature that we use sometimes at Behavior to let teams in meetings know that we’re straying from our goals and potentially introducing new levels of complexity and cost to a project. When he rears his ugly head, we can stop and take a moment to consider the real value of the new ideas we’re concocting. Sometimes the new ideas are perfect for the project and warrant inclusion, sometimes they’re nice but not appropriate.
Having the Scope Creep on hand in brainstorming or functionality meetings is great for gently and humorously reminding the team — and the client — to stay focused on the real user objectives and project scope.