Feature creep

Feature creep, creeping featurism or featureitis is the ongoing expansion or addition of new features in a product, such as in computer software.[1] Extra features go beyond the basic function of the product and so can result in over-complication rather than simple design. Viewed over a longer time period, extra or unnecessary features seem to creep into the system, beyond the initial goals.

Contents

Causes

The most common cause of feature creep is the desire to provide the consumer with a more useful or desirable product, in order to increase sales or distribution. However, once the product reaches the point at which it does everything that it is designed to do, the manufacturer is left with the choice of adding unneeded functions, sometimes at the cost of efficiency, or sticking with the old version, at the cost of a perceived lack of improvement.

Another major cause of feature creep might be a compromise from a committee which decides to implement multiple, different viewpoints in the same product. Then, as more features are added to support each viewpoint, it might be necessary to have cross-conversion features between the multiple viewpoints, further complicating the total features.

Characteristics

Feature creep is the most common source of cost and schedule overruns.[2] It thus endangers and can even kill products and projects. Apple's abandoned Copland operating system is an example of this.

Control

There are several methods to control feature creep, including: strict limits for allowable features; multiple variations, and pruning excess features.

Temptation of later feature creep may be avoided to some degree by basing initial design on strong software fundamentals, such as logical separation of functionality and data access. It can be actively controlled with rigorous change management and by delaying changes to later delivery phases of a project.[3]

Another method of controlling feature creep is to maintain multiple variations of products, where features are kept limited in some variations. Because the ever-growing, ever-expanding addition of new features might exceed available resources, a minimal core "basic" version of a product can be maintained separately, to ensure operation in smaller operating environments. Using the "80/20 Rule" the more basic product variations might support the needs of about "80%" of the users, so they would not be subjected to the complexity (or extra expense) of features requested by the other 20% of users. The extra features are still available, but they have not crept into all versions of the products.

At some point, the cost of maintaining a particular subset of features might become prohibitive, and pruning can be used. A new product version could simply omit the extra features, or perhaps a transition period would be used, where old features were deprecated before eventual removal from the system. If there are multiple variations of products, then some of them might be phased out of use.

Consequences

Occasionally, uncontrolled feature creep can lead to products far beyond the scope of what was originally intended. For example, the video game The Elder Scrolls: Arena was originally intended to be a "medieval style gladiator game",[4] however due to feature creep the game quickly expanded into a very large open role-playing game, spawning several sequels. Another example of this is the game Shogun: Total War, which was originally intended to be simply a "B-grade"[5] combat simulation game, but also expanded to produce multiple sequels. Microsoft's Windows Vista was planned to be a minor release between Windows XP and then the codenamed Windows "Blackcomb" (Windows 7), but it turned out to become a major release which took 5 years of development. However, a more common consequence of feature creep is to produce the cancellation of the product, which almost invariably becomes more expensive than was originally intended.

See also

Related concepts

Mitigation

References

  1. ^ J.M. Sullivan (8–10 June 2005), "Impediments to and incentives for automation in the Air Force", 2005 International Symposium on Technology and Society: 101–110, doi:10.1109/ISTAS.2005.1452719, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1452719 
  2. ^ Davis, F.D. and Venkatesh, V. (February 2004), "Toward preprototype user acceptance testing of new information systems: implications for software project management", IEEE Transactions on Engineering Management, 51 (IEEE Transactions on Engineering Management) issue 1 (1): 31, doi:10.1109/TEM.2003.822468, ISSN 0018-9391, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1266852 
  3. ^ Kenneth S. Norton (2001), Applying Cross-Functional Evolutionary Methodologies to Web Development, paper in Web Engineering: Managing Diversity and Complexity of Web published by Springer, ISBN 3540421300, http://books.google.com/?id=Ak5slktYul8C 
  4. ^ Ted Peterson Interview I, By Morrowind Italia, 2001-04-09 - Planet Elder Scrolls
  5. ^ The Making of: Shogun: Total War, By Kieron Gillen, August 24th, 2007, Rock, Paper, Shotgun

External links