The tendency to add just one more thing. Often spoken in reference to software.

Feature creep’s deleterious effects apply both technically and socially. In technical terms, the item under development grows ever larger, and hence more complex and fragile. In social terms, completion of the project either gets set back, becomes more expensive in terms of time and attention, or becomes burdened with increased pressure to implement and maintain the growing list of features on the development side. On the user side, there is a sense that all problems may be solved later, just as soon as feature X is added.

The user may grow to defer learning how to do certain tasks with the current software in anticipation of the new features. An expectations trap develops for the user-developer relationship. Feature creep encourages also the upgrade treadmill approach to software, in which people upgrade in the face of their expectations for improved performance. What often happens, though, is that they trade new bugs for old bugs. Knowledge of how to do certain tasks with the software becomes rapidly obsolete and the user must continual “learn” how to use new features, or as is often the case, old features that have been transformed in appearance or presentation.

As the community becomes accustomed to the constant motion prompted by feature creep, it fades into the background and its effects become hard to notice. A disconnect then develops among those who are related through the software. The developer, in the user’s eyes, becomes someone who can never get it right the first time. The user, in the developer’s eyes, becomes a yawning chasm of unfulfilled need, the source of ever-expanding unreasonable demands.

Feature creep is a manifestation of the idea that technical “progress” can solve our problems.

Compare to TechnologySolution and contrast with CommunitySolution. Note FeatureKarma and TooManyChoices for similar points.

These pages, ironically, demonstrate the problem--they stand as neologisitic ways of saying the same thing. “Feature Creep” is more widely used and recognized. Say “feature creep” to someone with a modicum of computing experience, and they’ll know what you’re talking about--say “feature karma” to them, and they most likely will not.

Consider, for instance, the results of a current google search: the top hit for feature karma is the MeatballWiki page that defines it. Subsequent links in the listing point back or refer to or derive from this page, or are mostly accidental juxtapositions of the term. None of them indicate that it has been accepted into normal use.

The search for feature creep, however, is headed by the JargonFile definition. Subsequent links are largely independent uses of the term which make no reference back to the Jargon File lexicon, but in context use the term to describe the same phenomenon as described in the lexicon.

Granted, google hits will change over time, nor is any dictionary to be taken as a prescriptive text. But as tools to capture the prevalence in common usage of a term, the two serve well.

If one seeks to describe the world and to be understood, then one uses the existing term. If one wants to try to be a fashion leader, one invents a term and tries to promote it.

On the other hand, “creep” is plainly perjorative, whereas “karma” represents a neutral approach. So, the one term inherently favors sparsity of features, whereas the other recognizes that one person’s irrelevant increase in complexity is to another person the one essential that makes the project useful or attractive or accessible.

See Also

EditNearLinks: MeatballWiki CommunitySolution FeatureKarma JargonFile