Functionality = Liability ?
Bloat is a word I hear thrown around a lot in my circles, for all the wrong reasons, and in all the wrong ways. Though it is relevant to everyone, it isn’t appropriately well understood. The nature of the word makes its meaning in a phrase rather clear, when in fact it is decidedly ambiguous.
Functionality is an unavoidable consequence of software development. Though programs are conventionally spoken about as ways to automate manipulation of symbols, and this is debatably true, they’re really more a means to an end. If you abstract enough, Vim is an input-handler-file-parser-syntax-highlighter, but it’s really just a text editor. The end is editing of text with variable efficiency, and vim is the means to accomplishing this for some.
This is accomplished though Features. In Word, formatting text is a Feature, and so was Clippy. These specific features are thought to be a pretty awesome thing by at least one person, normally the implementor or the person writing the implementor’s paycheck, but this does not guarantee that these things are worth what they actually cost, or are even a good idea.
Features aren’t Free
They may sometimes be free as in freedom, but they are never free in the terms of developer time, tax on the computer, and program complexity. Even if the initial time cost of implementing something is low, every feature is almost a BDFL, and as Zizek would tell you, those are the hardest to oust. They mandate things, like extra maintenance, work on backwards compatibility, UI/X design, and general complexity, and it is very hard to justify, logistically and otherwise, the removal of a feature from your project.
Not horrible, but not costed
Features aren’t Horrible, but they are shadow costs, gremlins in piping, and weighted clothing a la Dragonball for your computer nerds at every level, slowly tangling up every aspect of a project that is not actively battling against them. They need to be evaluated holistically, or they will end up being a poopy X-factor.