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.
