The benefits of feature requests or how to stop paying for things you don't use

Imagine a Swiss knife in which manufacturers have added the maximum number of tools, from nail files to pliers on the blockchain.
How many of them will be used in reality? Are customers willing to pay for other tools whose only job is to take up space and pull away their pockets? In this sense, some enterprise-level applications are like Swiss knives in a cube. Manufacturers fill them with every possible function with insane redundancy, without taking into account the real needs of customers. In this article, we will tell why redundant functionality is disadvantageous for users and how to avoid it.

90% of consumers of enterprise solutions use only 5% of their capabilities

The problem with enterprise-level products is the large number of redundant features that developers add to them. And since any solutions need regular updates, they add more and more features aimed at a small part of the target audience.

At the same time, enterprise level products are characterized by complex code base, high reliability requirements, long development time and long exploitation period. Therefore, their manufacturers do not strive to keep up with current trends in development, but rely on stability. Often the developers of such products do not know the actual needs of users, because they do not take into account requests for added functionality from real consumers.

As a result, there is not just redundant functionality, but a set of features that only 1-5% of users need. For example, the solution of American giant VMware is a huge constructor of features, most of which are not used by ordinary consumers. And about 90% of users need only 5% of the platform’s features.

Parkinson’s law plus Moore’s law

Parkinson’s Law states that any activity takes all the time it takes. Likewise, enterprise-level software can ramp up features until they take up all the resources provided.

For a long time, Moore’s Law was in parallel with Parkinson’s Law. According to Moore’s Law, every two years the number of transistors in chips doubles. This meant that software manufacturers did not have to think about whether there was enough performance for it. So they added more and more features without regard to the hardware’s capabilities. However, Moore’s Law no longer works. Meanwhile, major vendors continue to release software with redundant functionality. There may be several reasons for this:

• due to the lack of handling requests for added functionality from customers, the developer does not know the real needs of most of their customers;
• customers are too different and each of them needs different functions;
• it is important for the vendor to release regular updates, adding any functionality that wasn’t already in the application.

What’s wrong with redundant functionality

It would seem that much is not little. What’s wrong with a product containing some redundant functionality that may be needed in the future? There are several reasons to avoid redundant functionality.

First, such products are more difficult to use and harder to understand. It requires several high-level specialists to work with a large number of functions. Besides, a program with redundant functions loses its lightness. It is more difficult to operate, it needs more resources, and the price of such a solution will be higher than analogues. At the same time, customers pay money for features they will never or hardly ever use.

The solution is YAGNI and requests to add new features

“Implement only the features you really need, not the ones you’ll need in the future.”
Ron Jeffries, co-author of Extreme Programming and the Agile Manifesto

In response to the problem of implementing redundant functionality, the concept of YAGNI was born. The acronym stands for You ain’t gonna need it or “You won’t need it. At the heart of the YAGNI principle is the rejection of redundant functionality in software development as one of the core values of the product. The developer only adds features to the product that are really needed.

A simple way to understand what functionality will be relevant to consumers is to process their requests to add new features.

For example, in our project we staked on the simplicity and lightness of the solution. Users decide for themselves whether they need this or that feature. The features they need can be activated and those they don’t. You will only be charged for what you actually use, not for the entire package. If a client needs some extra functionality, he can make a request to add a new functionality and get it individually.

This approach allows the company to save money on unused features and still get all the functionality they need.