Less is More

One of my flaws as a writer is that I say too much. I find it really hard to cut out as much as I need to. Sometimes I come up with a good turn of phrase, and I just can’t let it go. However sometimes I need to. It’s not that the sentence or paragraph itself is wrong or bad in any way. It’s just that it no longer fits into the whole fabric of the article or book. Sometimes the article or book simply needs to be shorter. Even if every single sentence is well-written and conveys valuable information, sometimes the interest of the audience dictates that you say less rather than more. It’s a rare author who can keep an audience’s interest on the Web for more than a couple of thousand words, and I’m not one of them. Sometimes you have to cut just to keep the size down.

Software development is much the same. When designing an application it’s important to keep the feature count down to a manageable and comprehensible level for the intended users. Sometimes this requires you to cut features that considered indivdually seem valuable and useful. Software products today are rarely subject to the sort of hard size constraints one might find in a book or article, which makes it even more difficult to cut features. It takes exceptional judgement to determine when the cognitive load imposed by one more feature outweighs the benefit of that feature. Many developers flat out refuse to consider it. Nonetheless they need to. One of the few developers to get this right (not surprisingly) is Apple. Applications like iTunes, AddressBook, and iCal do less than their competition and this is a good thing. It’s not just that Apple knows how to better design user interfaces. It’s that they know when to stop.

APIs have the same issue. Many libraries add every feature a user asks for, because why not? it won’t hurt anybody, right? But more is not always better. Sometimes it’s worse. The inflection point can be hard to identify, but I’m convinced it exists. There is a point at which adding extra methods and classes makes the API and library harder to use, not easier. There is a point where the cost of finding the method you want outweighs the increased likelihood of it being there.

I suspect there’s a general principle at play here that goes beyond software. For instance, in designing massively multiprocessing systems like the Connection Machine or Virginia Tech’s Big Mac, a big problem is making sure the processors don’t spend more time syncing up with each other than they do calculating. Fred Brooks identified a variant of this problem in The Mythical Man-Month thirty years ago. Past a certain point adding more programmers to a late project makes it later. With a little thought I suspect you can remember similar examples in sports, education, politics, and other endeavors.

But bringing the focus back to software development, it’s important to keep a tight rein on features. For every feature you’re asked to add, don’t just ask yourself if it’s a good feature. Ask yourself if it’s good enough. How many people will it help? How much will it help them? If it’s going to help a lot of people, or help a few people a great deal, then go ahead and add it. However if it’s just a minor improvement, or is only needed by a few people, seriously consider leaving it out. Size carries real costs and those costs are too often ignored.

This entry was posted on Thursday, May 11th, 2006 at 8:05 pm and is filed under Software. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.