Avoiding Feature Bloat
When designing a new system, it is frequently necessary to make decisions about specific features to be included. Less frequently, however, one also needs to decide to remove features that are not necessary or cannot be supported by the development group.
Such decisions are important because they shape how the application evolves over time. Simplifying an existing system is sometimes even more important than adding features: a system that has a lot of unnecessary features may be hard to evolve and maintain. It may also hide an uncommon number of bugs.
Unnecessary features are poisonous for maintainability. Not only it costs more to maintain. Feature bloat also causes the system to keep bugs for a long time, simply because the affected code is not frequently exercised.
I have found over the years that, after an initial design, it is always helpful to determine what can be removed from the list of requirements of a project. This gives designers the great opportunity to consider what is really important and what is merely useful but not necessary for the central functionality of the product.
What to Remove
A number of approaches can be taken when considering such feature reductions. First of all, imagine what would be like to live without a feature. If you think a functionality is optional, just remove it from an initial release. In general, the first release of a piece of software should contain only the most fundamental functionality.
Having non-fundamental functionality in an initial release is a sign of a number of weaknesses. First of all, it probably means that you should have released the product earlier. Doing so would have resulted in additional feedback, which is always useful to improve the application. If the core functionality is not good enough, then there is no point in releasing additional features.
Releasing early is also a good way to get feedback from users on what they really want. Many users will gladly tell you what they think of a product and how it can be improved. This is the best type of feedback, because it comes from someone that has a true interest in using your software.
All things being equal, it is better to have users that will start with a software that contains only the core functionality, and have them tell you about the additional features they need. If there is interest in your product they will get back with ideas for improvement that can be introduced into the next version. On the other hand, if the core functionality of the product is not important for users, then you will probably have no real need to continue testing and improving those features.
Conclusion
Designing a complete product with lots of features may seem attractive at first, but it usually doesn’t work because you don’t know in advance the customers’ real needs. It is generally better to remove features that are not part of the core functionality of your system. This can not only save precious development time but also allow you to focus on what really matters in an application.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
