More or less features?
Many projects and software developers want their applications to be aesthetically pleasing and simple to use. Both imply uncluttered interfaces. Others want their application to be as useful as possible. These two are good goals that most software developers should include in their check-lists. The problem starts when developers and designers confront with the how to accomplish it.
Bad reasoning type 1: Less is more
We want our program to be simple to use and one less feature means less clutter. If there’s some function that 90% of users don’t actually use then is better to remove it.
The problem with the argument presented above is it only really works if your application has only two features. Most modern applications include way more features than two.
Removing a feature 90% of users don’t use can somehow be terrible for an application? By itself, it may not have much of a consequence, at most, you may lose 10% of potential users. Yet, when an application is designed with this in mind, you may end up losing every single user. Let’s create a hypothetical scenario to illustrate this point.
Say we have a set of 10 features that 90% of users actually make use of and a set of 10 features 90% of users don’t use. According to the line of reasoning expressed at the beginning, we then should remove or never implement the second set.
However, this could mean our application ends up being useless to all users in our hypothetical scenario. The second set contains 10 features, 90% don’t use it, but we don’t know if the 90% that don’t use it are the same users across all features. It may very well be that feature one is used by the first decile of users, feature two by the second decile, and so on until we reach the tenth feature used by tenth decile.
The end result is that for every user the software lacks one feature they use constantly, all because we removed the features 90% of people don’t use.
Bad reasoning type 2: MOAR
We want as many users as possible and that our piece of software is useful for as many as possible, therefore, we will include any feature any user may possibly want.
The problem with this kind of reasoning is it assumes stuff like good aesthetic design and simplicity to use are not valuable features by themselves. There’s a trade-off, the more features you have the harder it is for your program to be easy to use and good looking. Not to mention other technical problems such as a more complex code base, harder to maintain, harder to document, etc.
Many users will simply not use applications that don’t meet a minimum requirement in the easy to use and aesthetic departments, in other words, you could end up losing most of your users in your quest to get them all.
Both approaches are misguided, yet they both contain some truth. The intuition from the first is that people won’t like your application if it’s too complicated and ugly, the intuition from the second one is the more features your application has the more likely it is to appeal to more people.
What we want is a piece of software that is good looking, easy to use and has many features. Duh!. Of course everyone gets that. The problem is stripping functionality away as in 1 and adding functionality as in 2 both lead to undesirable outcomes.
The defect of both thought process lies in their reductionist approach. They consider features individually instead of as parts of a bigger system. Both ignore Aristotle’s maxim: The whole is greater than the sum of its parts. The question we need to ask is not if a specific feature is used or not by some percentage of users. Instead what we should ask is what percentage of users have their needs covered by some set of features.
An application that seems to have been developed within the lines of good reasoning is, for example, Dolphin. It’s a good looking very functional file manager. It has a feature set that covers most of what any user needs from its file manager while still looking easy to use,well designed and offering a ton of customizability.
The question of adding or removing features becomes a systemic question, regarding how much it would affect the number of users our current feature set covers. If removing one feature reduces the number of users by a negligible amounts but increases the easiness of use and the aesthetic appeal considerably, then it’s worth removing. If adding one feature increases the number users who find our application useful by a decent margin, then it’s worth adding.
In other words, the MOAR approach to software development is flawed as is the one expressed by the motto “less is more”. These two approaches are exemplified by applications all over the place, Amarok is clearly an example of MOAR and many pieces of GNOME are examples of less is more. What we need is a more systemic approach.