Resisting complexity

Brent Simmons writes about the latest Internet-darling, Twitter. (It's a messaging service that I have also found interesting.) An experienced software developer, Simmons describes the urge that drives a good, simple product towards complexity:

"Entropy for software isn't disorder--it's more features. It's caused by people wanting more features. And wanting them quite reasonably and intelligently: wanting good and useful features."

Implementing new features that improve the product is how software evolves, but discipline on the part of the developers is how software thrives. Products that try to be everything for everyone soon suffer under the weight.

This applies to documentation, too. One example is a "quick start" guide that grows overly complex due to too many screenshots or the inclusion of troubleshooting information beyond the scope of starting to use the software. Sometimes this occurs because key reviewers impose it, other times it happens because the book is taken over by a writer who isn't aware of its role in the product suite. And sometimes it happens because new editions of books always get longer; that's just expected.

It happens with documentation-related applications, too. Adobe Acrobat Reader is a prime example. It now requires voluminous documentation just to describe how to use it to read other documentation. This complexity, and sluggish performance, has resulted in a backlash among some documentation producers. 

The best intended improvements--such as adding more information to a manual or new features for users--can have a cumulatively negative impact. And when a book, or application, is produced by committee there's no single person who can easily stop the inevitable decline. No single feature, or paragraph of new information, pushes the product over the line. But, as the saying goes, no single raindrop believes it is responsible for causing the flood, either.

Posted: April 8, 2007 link to this item, Tweet this item, respond to this item