Creeping featurism

As any author of a software with a relatively large user-base knows, users always want more features. No matter how complete and flexible your program is, there will always be that user who is dearly missing a "small feature" and thinks it's a big flaw that the program doesn't support it. The strongest weapon users use when whining for features is "make it optional", since "people who don't want to use it, just won't see it and no one gets hurt". I'm struggling with this phenomenon in ESMS for years, and yesterday at last I found an article in which the Perl-guru Mark Jason Dominus explains why "creeping featurism" in general and the "make it optional" demand in particular are so bad.

Here it is: Creeping featurism and the ratchet effect.

Just to make sure that the important points are retained for my future perusal, here are a few of the best portions:

"Creeping featurism" is a well-known phenomenon in the software world. It refers to the tendency of software to acquire more and more features, to the ultimate detriment of its usability. Software with more and more features is harder to learn to use; it's harder to document effectively. Perhaps most important, it is harder to maintain; the more complicated software is, the more likely it is to have bugs. Partly this is because the different features interact with one another in unanticipated ways; partly it is just that there is more stuff to spend the maintenance budget on.

He uses the Perl manual as an example of something that grows ever bigger due to user requests for "features", which in this context are to-the-point explanations of finer and finer points.

But the benefit, such as it is, comes in one big lump, whereas the cost is distributed in tiny increments over a very large population. The benefit is clear, and the cost is obscure. It's easy to make a specific argument in favor of any particular addition ("people might be confused by X, so I'm going to explain it in more detail") and it's hard to make such an argument against the addition. And conversely: it's easy to make the argument that any particular bit of text should stay in, hard to argue that it should be removed.

As a result, there's what I call a "ratchet effect": you can make the manual bigger, one tiny notch at a time, and people do. But having done so, you can't make it smaller again; someone will object to almost any proposed deletion. The manual gets bigger and bigger, worse and worse organized, more and more unusable, until finally it collapses under its own weight and all you can do is start over again.

And the best point is here:

And these people sometimes get quite angry when I tell them I'm not going to put in the feature they want. They're angry because it's easy to see the benefit of adding another feature, but hard to see the cost. "If other people don't like it," goes the argument, "they don't have to use it." True, but even if they don't use it, they still pay the costs of slightly longer download times, slightly longer compile times, a slightly longer and more confusing manual, slightly less frequent maintenance updates, slightly less prompt bug fix deliveries, and so on. It is so hard to make this argument, because the cost to any one person is so very small! But we all know where the software will end up if I don't make this argument every step of the way: on the slag heap.