Pablo Fernandez asks 37signals:

Do you really think is the lack of features what makes a software better, or is it the “illusion” of simplicity (hiding the less used features, and emphasizing the common ones).

I don’t think the number of features is what makes software better or worse. One more or one less isn’t really the issue.

What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong” or “There’s a better way to say this.” Physical constraints create natural limits for books and museums. Books have pages and museums have wall space. Software, on the other hand, is virtual, boundless. Anything is possible. When anything is possible someone inevitably tries to make something do everything. And the more something does the harder it becomes to understand, grasp, and use. So the key is deciding what makes it and what doesn’t. This applies both globally (the entire inventory of features) and locally (what someone can do on the current screen they’re looking at).

It’s not about ten features versus seven, it’s about the right four versus the wrong eight (or the right eight versus the wrong four). It’s also about the right place and the right time to reveal the right features. Every feature, widget, or interface control competes. Loading up the screen with stuff that is used 10% of the time means the stuff that’s used 90% of the time has to fight for attention. That’s not a good experience. The experience should be light, flowing, and comfortable, not heavy, clunky, and frustrating.

Software is a recipe: Too much of any ingredient can throw off the balance. The wrong ingredients can spoil a dish. Great software is perfectly seasoned—just enough salt, just enough pepper. Too much of any one thing, or not enough of another, and you’ll send it back.

When we talk about Less Software we’re really talking about balance. We’re talking about finding that sweet spot that solves most of the problem with the simplest solution. Simple for you to develop, maintain, and support, and simple for your customers to derive maximum value with minimal effort, learning, and hassle. From Getting Real, the book:

The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.

It’s not so much about consciously saying “we have three too many features here” it’s about saying “let’s solve most of this problem with less code and simpler design.” If we need to solve more of the problem later we can, but let’s solve most of it now—and quickly. And most of the time the partial solution is the plenty solution.

So remember: Good software is about balancing value and screen real estate and understanding and outcome. If it takes 20 good features to get there, then great. If it only takes eight, even better. It’s not the number that counts, it’s the balance.

Got a question for us?

We’re looking for interesting questions to answer here at Signal vs. Noise. Got one? Then send it to us at (make sure the subject line reads “Ask 37signals”). We’ll cherry pick the most interesting ones and answer them here. Fire away!