Nearly a year ago, I shared my opinion that we live in an era of crappy quality. Now after reading a few books on DevOps and talking with people working in this environment. I wonder if the Feature bloat is not responsible for that.

What is Feature Bloat

As application lives longer and longer. The publisher is still developing and maintaining the app. It accumulates more and more features. Not always it is with benefits for the users.

Let’s assume you created a text processor – users are selecting your product because it is simpler, much faster and more reliable than the competition. Since you have a lot of users and a lot of money from it you decided to add new features. At first, users love them, but with the time you see less and less new users.
So you continue adding new features to the application.
But your app gets worse and worse scores. Your app is now as slow, as bloated as your completion and you have lost your niche. It’s not as popular and now doesn’t offer anything different so why anybody should stick with it?

I like the definition from It Law wiki:

Feature bloat is the tendency of a vendor continually to add unnecessary features to a product that are not of any value to most users, use more system resources than necessary, and often unnecessarily add to the cost of the product.

In the current world, we are adding new and new features to applications faster than ever. But the question is: Do we need to? I am one hundred per cent sure that heaving this ability is a great edge. But do we need to add so many features?

We leave in busy days and users has less and less time to learn what new in your app. For example, I stopped reading release not of Resharper cause I knew I wouldn’t remember what new features they bring in. I am only updating it so I can keep up with new versions of Visual Studio.

Now imagine all non-technical people who have other jobs to do. Example from my life There was a time when android did a lot of changes in how the UI looked and behaved every few releases. I remember in the past, my Father (and a lot of others) had problems with it. He doesn’t have time to learn the new layout, especially at the moment when he is in a hurry.

Yes, both cases are anecdotal evidence, but I want to make you think about the issue. I am not ready to build the case for it yet.

Another case is speed; there are a lot of articles about how everything now is soo slow.
And we have the strongest computers yet.
I won’t even start on how colossal failure for me the windows 10 is. Seriously after each release, I have more and more issues with it.

Above led me to this question.

Do users want such fast feature delivery?

The sad answer is yes. If your competition app has some feature giving it an edge over your, you can bet it will attract a lot of your users, unless you do something fast.

But the better question is.

Do Users want all the new features every day any day?

Unfortunately, I have no answers; my personal feeling is some yes the early adopters, geeks etc. But it is a safe bet to say that Pareto rule is at work here. 80% of users are using 20% of features (this is my guess I haven’t find research on the topic)

But What I found is research on features fatigue from 2005. There is this gem:

“Because consumers give more weight to capability and less weight to usability when they evaluate products prior to use than they do when they evaluate products after use, consumers tend to choose overly complex products that do not maximize their satisfaction, resulting in ‘feature fatigue.’”

So more features can bring you more customers. But it won’t satisfy them so the customer retention will be low.

DevOps and Feature Bloat

So DevOps is here to give us the ability to deliver faster and faster. As you can see, It makes me worried about feature bloat, and not only me:

One of the key advantages of DevOps is that it promotes continuous software delivery. That means new features can be released faster. But the ability to add features more easily also raises the risk that software delivery teams will add functionality to software just because they can, not because it’s needed. More features are not always better, even if you can implement them efficiently.

This made me think – since DevOps comes out of Kaizen, Lean, etc.
Which they all are concerned with waste elimination. I am curious why we see it only applied to the process, and I had struggled with finding examples of using it for the product.

Yes, I found a lot of articles on features bloat and how to prevent it. But looking for cases of companies that regularly removes features I struggled to find.

Well, Google has a track record of killing their apps. Not so much on the features front.

But you know what? In DevOps, you already have all the tools that you need!
DevOps advocates for monitoring and data collection, it also suggests a solution for feature toggles. So you should have all the tools for removing features that don’t see enough uses.

Lean was inspired by the Japanese way of work in Toyota.
So to inspire you, I will share with you what I learned in one of the Japanese gardens I visited.

The art is not in adding to the garden to make it more beautiful, art is in subtracting from it to make it more beautiful, to the point where you can’t subtract anymore without harming its beauty.

The Benefits of substation

These all are hypothetical, but your app maybe becomes faster, and less complex, more user-friendly. Who know maybe removing some features will allow you to do a redesign of UI for something much comfortable.

And as for new development definitely, cost of Maintenence and testing will go down.

The cons.

You need to know what to cut. There always be users that don’t like it.
Your app is maybe written in a way that you can’t cut it. But if that the case it probably also will hinder your ability to develop new features

Conclusion

Feature Bloat and feature fatigue are real issues, but so the need for constant deliver of “The new” to users. As with everything, we need to find the right balance.
And we won’t do it without paying attention to the issue.