A couple of weeks ago I came across a link to the book The Simplicity Cycle by Dan Ward. It's available as a free download so I grabbed a copy and finally got the chance to read it.
The book begins with the argument that projects follow a curve in the two-dimensional space formed by the qualities "goodness" and "complexity". Initially, all projects start off at the origin with no complexity or goodness. As they progress, complexity and goodness increase together as the initial problems are understood and suitable solutions created.
The book's primary thesis is that eventually all projects reach an inflection point where further increases in complexity yield less goodness, not more. To improve goodness beyond this point, the focus must switch from increasing complexity to reducing it. These transitions from simple, to complex, and back to simple again form the "simplicity cycle" which, when successful, results in "an elegant, graceful, and streamlined solution" capable of representing "tremendous complexity" while being "at once profound and breathtakingly simple". Inspiring stuff.
Not surprisingly, the author asserts that increasing complexity after the inflection point results in an undesirable outcome. For software, this could mean an application with too many features, options, or ways to accomplish tasks. For decision making, this could mean having too much information to draw an effective conclusion.
Unfortunately, the non-linear relationship between complexity and goodness can go unrecognized - from page 26:
One pitfall that designers, engineers, and academicians may fall prey to is the belief that continuing to increase complexity … will continue to produce increases in goodness. It just isn't the case.
In some cases, this mistaken belief can be due to a fascination with complexity itself - here goodness doesn't mean utility to the consumer but rather intellectual gratification to the producer. Also quoting from page 26:
This is genesis-gone-wild, cancerous growth. It is the product of “over-learning” and smugness, where people fall in love with complexity.
In other cases, the complexity is mastered but without achieving the deep insight needed to reduce the subject to its fundamental problems and solutions - to my mind a kind of mechanistic expertise. Quoting from page 30:
It generally means we are over-thinking a problem or over- engineering a solution. Think of it as achieving “the complexity on the other side of understanding,”
…
Here we find the learned academician who everyone assumes is brilliant because nobody can understand a word he says. In fact, his academics may simply be complicated and have very limited goodness. All those extra squiggles are not very useful, no matter how complex.
The book admits the difficulty of knowing when the inflection point has been reached. Guessing too late results in over complicatedness as has been discussed. However, guessing too soon results in premature optimization - an equally bad outcome as it fails to reach optimal goodness. Unfortunately, the author asserts that a method for reliably identifying the inflection point doesn't exist.
The book makes the important point that the complexity phase cannot simply be skipped. Quoting from on page 46:
However, the simplicity in this region is built upon an essential foundation of earlier complexity. We can’t just jump from simplistic to simple, skipping the complex entirely. The initial increase in complexity is as crucial to maximizing goodness as the later decrease in complexity.
The book concludes with examples of good and bath paths through the complexity vs. goodness space. I found these helpful for reflecting on how the simplicity cycle relates to past experiences.
This book was a pleasant surprise. Although short and free, I found it thought provoking and insightful. In particular, the "simplicity cycle" concept matches well with my experiences. When developing software, I often find that after writing a fair amount of code common patterns emerge that allow for a simpler design. Conversely, I've witnessed first hand the disastrous outcome of projects that fail to simplify after the inflection point. Although these experiences have given me a healthy fear of complexity, this book provided a context for that fear and a framework for managing it.
My only criticism of the simplicity cycle concept is that it may encourage the kind of over generalization that Joel Spolsky warns against in his essay "Don't Let Architecture Astronauts Scare You". Quoting from Joel's essay:
When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture. They're astronauts because they are above the oxygen level, I don't know how they're breathing.
The point I take away from this is that simplification is not the same thing as abstraction - simplification remains focused and actionable while abstraction becomes vague and unactionable. Unfortunately, I think many mistake generalization for simplification but now that I'm consciously aware of the difference I'll be less likely to fall into the trap myself.
