Most of the time what we often call simple is really “optimized” for some particular thing. To use the same example as Paul Homer mentions in the piece quoted below, if you purchase a food processor to speed chopping, and you use it for one small chopping task, you’ll most likely spend more time cleaning the parts than you saved with the speedy chopping, and now you have to store it, care for it, and add complexity to another aspect of your life. Not so simple eh? It may be optimized for the fact that you broke your wrist a week ago, and chopping is out but everything else is OK, or any other set of factors that might make what seems “less than the simplest thing” optimized as a solution. (BTW, cleaning it, storing it, and good knives explains why we don’t own one, for us/now that’s an optimization.)

Something that is simple when a problem is small is often not simple at all when the same problem is big. If I need to print one piece of paper and deliver it in a timely fashion there are so many solutions to the problem that “what is simplest” can be defined by other factors such as where I am, how much time I have to devote to this today, importance of the document itself… but if I have to print 50,000 items and deliver them in a timely fashion, or I’m the New York Times, the same solutions are not available. Other constraints narrow the number of solutions and complexity rises.

These are two aspects of the same concept… that we’re generally not simplifying, as nothing is simple, but we are optimizing for our current set of issues. And the important difference is that optimizations must be tweaked and maintained to remain optimal because our lives are not static, and the problem space grows or shrinks and certainly changes. “Simple for me is not simple for you” is a problem every business deals with in many ways. As a developer I run across this in interface design, and keeping code “simple”, and many other ways.

One of the things I hope to continue to get better at is “feeling the pain” sooner, being more aware of the shifts away from “maximally optimized” in order to ensure that more things remain as balanced as possible. It is an important skill to be able to retrospect with clarity.

My wife and I have been working hard on “simplifying” our lives, a multidimensional problem that encompasses who we were before we met and joined our lives, who we want to be together, our child, and so much more. By constantly looking at how we’re doing, and paying attention to the feedback presented by how we feel about things, we progress toward what we describe as simpler lives, but is really, a more optimized life at a given moment. Good enough.

The Programmer’s Paradox: The Nature of Simple: Without a measure, you cannot be objective so you really don’t know if you’ve simplified it or made it worse. In any multi-variable system of equations, you might use something like linear programming to find some ‘optimal’ points in the solution space, but you cannot apply a fixed simplification, at least not one that is mathematically rigorous. Finding some number of local minima is not the same as finding a single exact minimum value.