Programmer Musings

In Defence of Simplicity

Recently, Joel Spolsky wrote about Don Norman's article Simplicity Is Highly Overrated. Joel used this as a springboard to another talk of how simplicity doesn't matter in Joel on Software: Simplicity. He referenced and expanded on his views from Strategy Letter IV: Bloatware and the 80/20 Myth. As I've said before, I often find Joel's writing to be interesting and insightful, but sometimes I can't figure out what he is talking about. This is another of those times. You should read the articles referenced above before continuing, I don't want to misrepresent anyone's arguments,

I don't own a successful software business like Joel and I'm not a design guru like Norman, so my opinion may not mean as much as theirs. But, I have to disagree with the conclusions Joel draws in this articles.The first is that bloat isn't a problem. Although I do agree that you can waste time trying to slim down software unnecessarily, I don't think it is reasonable then to declare that reducing bloat is always a bad idea.

Any work on software involves tradeoffs. You need to determine what is the best use of the company's resources. Sometimes spending time optimizing software is not the best use of time. However, as the size of the code increases, there are other effects to consider:

* more code means more possibilities for error
* more code to read when trying to find and diagnose bugs
* more code means more work to train new people
* more chance for accidentally duplicated code

All of these items apply whether the extra code is due to more features or badly written code. If the extra code is due to features that your users want, the disadvantages are outweighed by the benefits (usually). However, if the code is due to features are truly not needed by your users or simply bad coding practices, there is no benefit to offset the disadvantages.

The developers aren't the only ones to see disadvantages in the extra code. The effects that the user sees are different, but no less annoying:

* program takes up more disk space
* program takes longer to load
* program takes longer to shut down (sometimes)
* program takes more memory

These effects can range from inconsequential, through annoying, to unusable. Different issues will be worse for different users or different usages of the program.

What is Bloat?

Joel seems to take the position that the extra code is always the result of a conscious decision to add code for functionality beneficial to the user. If that were the case, deciding that the extra features aren't bloat is probably reasonable. Unfortunately, not all extra code is the result of such careful consideration.

A lot of the bloat I've seen has been caused by inexperienced developers coding features inefficiently. I'm not talking about reducing the code size by using extremely cryptic twisted code. I'm talking about the case where someone is storing data in a list and then writing linear search code a dozen times to find items in that list. Or, maybe the case of the inexperienced programmer that writes his own sort algorithm when the library provides one already.

There is also the case where a developer adds a feature for free because it was easy or because he felt like it. If no one wants or needs this feature, it is bloat. As the code gets larger, there's also the phenomenon of partial implementations of features that get left in the code so I can finish it later. These things all add bloat to the code without adding any features for the user. As such, I believe that Joel or anyone would have to admit that this kind of bloat is bad.

Simplicity and User Choice

Now, I'd like to turn to Norman's argument. Based on some of his earlier work, I'm assuming that his article is not saying that simplicity is bad. Instead, what I think he means is that the consumer does not always appreciate simplicity. Often, this does appear to be the case. However, one of my favorite Bruce Schneier quotes is

The user's going to pick dancing pigs over security every time.

People sometimes choose more features even when they don't need them, and won't use them. People also chose sweets instead of healthy foods and sitting on the couch watching mindless television to exercise. This does not mean that sweets and watching television are better than the alternatives, it just means that people do not necessarily make the best choices. This is meant more as an observation than as a judgement. I suspect that Norman's article is the same kind of observation.

Simple Successes

My final point involves actual examples of simplicity that people do choose. The first is everyone's poster child for simplicity, the iPod. I don't believe that the iPod shows that removing features makes a successful product. I'm pretty sure that Apple did not start out with a jukebox-size product and start removing things to make a jukebox lite. Instead, they appear to have carefully considered what features people really want and use in a portable music player. Anything that was not essential, they removed. They also focused on making it attractive both physically and with careful marketing. The result is a success. Note that this was the result of real engineering tradeoffs, not just slashing features.

The second example would probably annoy Joel, given his fondness for using Mozilla as a bad example. After years of work, the Mozilla Suite was a clean, powerful implementation of a full-featured Internet client. The browser was coming along well and the people who used it, liked it. Then came Firefox (as Phoenix). This browser was the result only including the parts of the Mozilla client that was absolutely essential to browsing the web. The result was much simpler than the full Mozilla Suite, and people liked it. The development team then began to add functionality that enhanced the browser, without branching out into the other parts of the Internet client space. In the process, Firefox has gone from no market share in November 2004 to around 12% in late 2006. In Europe, the adoption rate appears to be higher. Given that most computers do not come with Firefox installed, anyone who uses it has to install it for themselves. The people that are using Firefox have explicitly chosen to do so, unlike the larger percentage of people using IE.

Once again, this is not the result of randomly removing features that most people don't use, Instead, Firefox seems to be the result of a strong focus on what is actually needed in a browser to improve the user experience. If a feature does not meet these criteria, it appears to be left out.

Conclusion

In my view, simplicity is a desirable feature of a product and bloat is an undesirable (mis)feature. However, simplicity is not the only criterion by which a product should be judged. The development of any product involves tradeoffs, making the wrong tradeoffs usually causes the product to fail. In general, competing with a feature-rich product with a stripped-down product usually won't succeed. Under the right circumstances, simplicity, elegance, good design, and marketing can complement a deficit of features.