Worse Is Better

This post is a part of the software design principles posts.

Let’s say we want to create a mobile application.

Our application has some features, functionalities and… bugs.

Sometimes, when we develop programs we create some bugs. This is just a part of our job description, right? 😅

Some of them are majors, so we have to fix them, but some of them are minors and this post will concentrate on them.

We have minor bugs in our program. What can we do about it so our customers would like our program even more?

1. Fix them
2. Invest our time for developing new features

What should we do? How can we choose correctly?

Let’s start with defining what makes our program “good”:

1. Customers like it
2. It’s easy to maintain
3. No bugs
4. Broad test coverage

Developing new features may make our customers like it more. Fixing minor bugs will make our program better.

The meaning of “worse is better” according to Wikipedia:

It is the subjective idea that quality does not necessarily increase with functionality—that there is a point where less functionality (“worse”) is a preferable option (“better”) in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.

In our case, choosing to develop a few features (“worse”) without bugs (“better”) instead of writing many features is the right thing to do.

In other words, sometimes, we should fix our code before continuing to develop new features even if it means that our program has fewer features. It’s relevant to refactoring the code and enlarging the test coverage as well.

 

Which one is better for you? It depends, but remember that you don’t expect to buy something which has bugs even if it’s minor.

 

If you have any questions feel free to comment or contact me directly.

Thank you for reading this. Please share and visit soon again,

Orian Zinger.