The logic behind “worse is better”

In the bid to make your software competitive, a common mistake is adding more and more functionality. But sometimes in software, worse is better.

Or so Richard Gabriel, author of the MIT paper The Rise of Worse is Better, says.

Of course, this statement seems altogether too paradoxical to be of any use. But there’s sound reasoning behind it. Here, we explain the logic behind “worse is better”.


What is “worse is better”?

“Worse is better” is a software design principle that advocates for simplicity over functionality. It suggests that limited, simple to use software is more appealing than difficult programs with all the bells and whistles.

That is, software quality doesn’t necessarily scale with the number of features and functions you have. “Worse is better” posits that there is a point where less functionality (i.e. ‘worse’) is preferable. And the reason it’s preferable is due to increased usability and practicality.


The key characteristics of “worse is better”

Put into practice, “worse is better” revolves around four key characteristics.

  • Simplicity

The most important characteristic to “worse is better” is simplicity. Both the implementation and the interface of your software must be simple. This means that your program must be easy to use to get the desired result, preferably with a clean, simple user interface.

  • Correctness

Next, your software design must work correctly. This means that for every input, it delivers the expected output, without error. (In other words, it does as you expect it to do.)

  • Consistency

The third key characteristic of a “worse is better” design is its consistency. That is, your software design should not be overly inconsistent. This means that the design of your software should be somewhat predictable and intuitive.

  • Completeness

Finally, “worse is better” isn’t a way of saying ‘bad’ or ‘broken’ software. Your program should provide a whole experience — solve the entire problem it’s supposed to solve.


The logic of simplicity

The point of any software program is to solve a problem or pain point. When you keep your software simple by following the “worse is better” principle, you ensure that you don’t lose this core function of your program.

A common issue in software is feature creep. This is where a program gains so many features, bells and whistles that it becomes difficult to use. The user interface becomes cluttered to accommodate the mass of features, and the software becomes unruly to use and to maintain.

In contrast, a simple software program keeps its core functionality at the front and centre. With worse is better, the program won’t do all the amazing things a complex system can. But it does get the job done quickly and effectively. It’s easy for users to pick up, understand and use. Plus, it’s less code for the development team to maintain and secure.


Rejecting complexity

Other software practices support the “worse is better” software design principle. They all work to reject overly complex software, feature creep and overengineering.

For a start, using a minimum viable product (MVP) forces you to avoid adding extra features at the start of development. This can help you keep your core functionality clear. So, when you build up your software, you can make sure the new functions will fit your software goal.

YAGNI (you aren’t gonna need it) is another practice that can help you maintain a simple, “worse is better” software design. This is because, with YAGNI, you are making sure you aren’t building any features until you know for certain that they are needed.

Lastly, the MoSCoW method can help you ensure that each planned feature is integral to your software, and so fits into a “worse is better” design. It’s a prioritisation technique that sorts features into ‘must have’, ‘should have’, ‘could have’ and ‘won’t have’ categories. For a “worse is better” approach, you’d stick to the features in the ‘must have’ and ‘should have’ categories.


Worse is better

In short, “worse is better” is all about avoiding the folly of feature creep and overengineering. It recognises the value of simplicity and reminds us that sometimes, fewer features make for a better experience.


Useful links

The 4 software maintenance categories and what they mean for your users

Yes to YAGNI

Software development and the MoSCoW method