Loss of Features is Progressive

Software bloat is never desirable, even when naysayers pretend it is.

May 16, 2025

Someone posted again. Scrolling through my morning’s Mastodon timeline, I once again saw an assertion that the current version of GNOME was inferior to earlier versions. The stated reason was that current GNOME has fewer features. The exact wording was that it had thus “regressed” because of its design choices.

Now, what I’m about to say doesn’t just apply to desktop environments on non-mainstream operating systems, but software as a whole.

Among a very particular flavour of power user, there is an often unstated belief either in software maximalism, or in compositional maximalism. The former case is quite simple; Software maximalism is the belief that software gets better as it gains new features. The latter is a stated belief in minimal software, but with the additional caveat that software should be built in such a way that savvy users can combine various features of software in order to build their own entirely idiosyncratic workflow.

Both forms of maximalism are not ideal for users, including power users. As previously mentioned here, features which help to automate certain tasks always incur some kind of management overhead for the user. There’s no point in automating a two-click process if the user has to frequently open a management panel to change some automation rules around. The linked article includes an example for how it is likely pointless to ask a user to select favourites if you can also simply order a list of options by frequency of use, and the same is true for composition-maximalist users who often need to adjust their custom computer automation scripts as new use cases arise. For software which is inherently maximalist, often a user has to make dozens of meaningless choices which ultimately don’t change their experience. These approaches to software usability optimize for flexibility where none is needed.

Ultimately, when I’m working at the computer (for various definitions of that word), I am making choices as to what to do. I’m browsing the web, I’m choosing what to read, I’m watching some informative and entertaining video, listening to stimulating music, playing some games, and whatever else. Whichever app I’m using, I don’t really need to choose how to arrange keyboard shortcuts in the app, especially not for things which I can do in two of three clicks. I don’t need the ability to choose whether browser or folder tabs appear above, below, or to the side of content. These kinds of ancillary choices not directly related to the task at hand are a burden on users.

The question all good software designers ask is “If I took this feature away, would the user still be able to do what my app enables them to do?” and, if the answer is yes, then that designer begins considering how removing that feature would make the app easier to use. An adjustable wrench may be more useful in more cases, but that feature is a liability that leads to eventual breakage—not to mention that an adjustment mechanism is itself fragile in ways that an entirely rigid wrench isn’t. In this same way, software with fewer moving parts and fewer quality of life features can be preferable to power users who need to get a lot done. With fewer distractions, detractions, bugs, crashes, faults, and failures, the power user can charge boldly ahead with what is actually important.

It might sting to lose features in software you use, but in most cases it’s easier to relearn how to stay on the “happy path” laid out for you by those who’ve come before than to clumsily forge ahead through uncharted and unmaintained territory.

What really irks me about this attitude that certain software becomes worse when features are removed is that it is applied in a very selective way. Software developers, engineers, users, and enthusiasts all generally agree that bloat is bad. Bloated software is difficult for programmers to reason about it’s difficult for designers to iterate on, it’s difficult for users to understand.

Why do certain software packages get lambasted for their leanness?