12.17.06
The Laws of Simplicity — John Meade
I recently read The Laws of Simplicity by John Maeda. It proposes an explanation why the iPod is selling so well (you guessed it, simplicity), and why both simplicity and complexity have their place in our lives. I’m sure Maeda already thought of this, but here are my thoughts with respect to writing code.
Too many coders are interested in complexity, and too few in simplicity. While our goal should be to boil it all down to produce a simple API for the others to use, this rarely happens. Consider the following instructions.
1. Install the package, startup.tgz
2. First, read the Sizing Document to assure you are using the correct number of nodes.
3. …
The instructions are already broken. Step 2 should come first, or better, it should not exist. Taking away the obvious helps the instructions work more smoothly.
Here’s a coding example. Once I worked on SOAP (ironically ‘S’ stands for Simple), a standard so complicated, that no two different SOAP implementations ever seem to talk to each other. SOAP seemed to be complexity for the sake of complexity. After running through the hello world example, I had a number of files to deal with.
quote.xml
quoteGetQuote.xml
quoteAddStock.xml
quoteGetMultiQuote.xml
Every function had an xml file to describe it! I responded quickly by erasing every xml file through the Makefile to keep the future coders’ life simple. These files added nothing to the system. The point here is that I always need to delete and delete until nothing is left but working code.
Maeda’s conclusion is one I believed for a while, though he is more articulate than I in making the point. Simplicity is not necessary making the whole simple, but hiding the complexity that does not serve the user.