These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.
Feature creep may also arise as a result of compromise from a committee implementing several different viewpoints or use cases in the same product, even for opportunistic reasons.
Later feature creep may be avoided by basing initial design on strong software fundamentals, such as logical separation of functionality and data access, e.g. using submenus that are optionally accessible by power users who desire more functionality and a higher verbosity of information.
The extra features are still available, but optional and ready to be utilized for those who solicit them, but they have not been implemented into the basic versions of the products.
A common consequence of feature creep is the delay or cancellation of a product, which may become more expensive than was originally intended.
[citation needed] Often, a reasonably feature-complete software project, or one with moderate amounts of feature creep, can survive and even thrive through many iterations, but its successor release may suffer substantial delays once a decision is taken to rewrite the whole code base in addition to introducing new technologies.
By that time, Microsoft's Internet Explorer browser had long-eclipsed Netscape in usage share, which had diminished to single digits.
Just a year later, a group of Mozilla developers decided to separate the browser component, which eventually became Firefox.
The desired change may be large enough to warrant a redesign of the existing project foundation, but deadline pressure instead requires developers to rush and put out a less-refined product.