💾 Archived View for yujiri.xyz › software › features.gmi captured on 2023-06-14 at 14:54:07. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Features are costs

In The Philosophy of Minimalism I claim that the practical cost of complexity is often much higher than non-minimalists think.

The Philosophy of Minimalism

Here I'll point out some concrete reasons for this, specific to software.

Not only do features take time to learn, but *less important features impede your learning of the more important ones*, because you don't always know which features are the most important until you learn them. The perception of a lot of features can even result in users *never* investing the effort to learn them all, like I did when I played Starcraft.

Relevant: simplicity in game design

Features make it harder to avoid bugs, especially since a linear increase in features causes an an *exponential* increase in the number of ways they might be used together.

This mostly applies to things like languages and frameworks, but different ways of doing the same thing mean different users might prefer different ones, which can make it harder for them to understand each others' work and collaborate.

For formats and protocols, it's even worse because features raise the cost of implementing them and lead to incompatibility.

Specifications are contravariant

Lastly, this doesn't concern the end user after it's done but the opportunity cost of development is massive. Any time the dev spends adding a feature that isn't needed is time not spent adding one that *is* needed, or fixing bugs, or doing something else of value.

Kill software for great glory

One of the many excellent quotes at cat-v is: "Normal people believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet."

http://quotes.cat-v.org/programming/

I think this insight is very underrated: *features are costs*. *Functionality*, defined as "the extent to which the software makes things easier than they are without it", is good, and *features*, which are "the quantity of the means by which it provides functionality", are bad. Features are the cost you pay to implement functionality, and you better pick your battles (another excellent cat-v quote: "In programming the hard part isn't solving problems, but deciding what problems to solve.").

It's like complexity versus depth in game design.

Depth in game design

You can have either one without the other. For example, GNU Nano is an editor with relatively few features, but a lot of functionality. `find` and `git` are programs that have tons of features, but achieve tons of functionality with them. QuickBooks is a program that has a staggering amount of features and achieves surprisingly little functionality.

contact

subscribe via RSS