The Simplicity Cycle (Dan Ward)

I originally published this recommendation long before the book "The Simplicity Cycle" was available.

It is now on sale at Amazon and will be released May 10, 2015.  Hence, this republication.

My Introduction for Dan Ward's book ,The Simplicity Cycle, but which also includes a description of and a recommendation for his book FIRE. The two books make a powerful package. (This introduction has been slightly modified to make it work as an essay about and a recommendation for both books.)

Ward, D. (2014). The Simplicity Cycle. New York: HarperBusiness. Simplicity Cycle on Amazon.comWard, D. (2014). FIRE: How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation. New York: HarperBusiness.  FIRE on

The Simplicity Cycle

The Simplicity Cycle is a simple book about a complex topic, but don't be fooled. Beneath the simplicity lies a deep and profound message. Complexity is often necessary, but unnecessary complexity complicates our lives. How can we strike the proper balance? Ah. Start with this delightful book.

For me, there are at least two rather different forms of simplicity. The first, which is the primary focus of Dan Ward's book, is that of physical things. For example, the simplicity of a kitchen knife contrasted with a commercial jet airplane or perhaps the simplicity of finding a web page versus filling out an income tax return. For these things, complexity refers to the number of separate parts and the interweaving of relationships among them. Something simple has few parts, and moreover, part that are simply connected to one another. Note that for these things, some degree of complexity is essential because we expect our devices to do many things for us, which requires them to be complex. The trick is to eliminate needless complexity.

The second form of simplicity is cognitive - in the head. Here, different people will judge the same item quite differently. Consider, for example, the cockpit of a commercial jet airline. Complex? Yes, but is it needlessly complex? Here it is important to consider whether those controls are readily understood or not. If not call them complicated, as in confusing. To most of us, all the controls and displays of the airplane cockpit are incredibly complicated. But an experienced pilot, might think them quite simple. Cognitive simplicity means understanding, it means having a good model of how everything works. The experienced airline pilot understands the function of all of the multiple controls and displays and thinks of them as a logical structure for controlling the airplane and understanding its state. The non-pilot, however, only sees a large number of confusing controls and displays and has no way of knowing how they relate to one another or what they do. To the pilot, the complex device is simple. To the non-pilot, the same complexity is confusing and complicated.

Both physical and cognitive complexity share many features. Among them is the property of modularization. That is, even the most complex things can seem simple if organized into logical groups of components  -- modules -- that can be considered separately. When there is good modularization, the device is easier to design, to build, and then to use. Why? Because each module can be relatively small and simple. Each of the separate module can be designed, constructed, and learned independently of the others. This is why modern smart cellphones can seem so simple despite the large number of different things they can do and the resulting internal complexity. The phone and its many applications are designed as separate modules, each presenting only the controls and information relevant to the task at hand.

The real evil in complexity comes when the thing has no apparent structure. When it cannot be decomposed into somewhat independent modules, so that it is necessary to understand the whole thing at once, because all the separate parts are interconnected and affect one another. That's why the tax code is so difficult. And why some large physical projects can be so difficult to build on time and within its prescribed budget.

Dan Ward, FIST, and FIRE

I first encountered Dan Ward in 2011 when we corresponded about an early edition of this book. I was working on my own book about complexity - the cognitive kind - and it soon became clear that we shared similar viewpoints. Dan, I quickly discovered, is an officer in the U.S. Air Force, working to streamline the way that complex projects are developed. In 2012 he wrote that "I was just offered a position at the White House Office of Science & Technology Policy. They want me to help lead an initiative to implement my FIST (Fast, Inexpensive, Simple, Tiny) concept across the US government - starting with the DoD, but also NASA, Department of Energy, etc." Neat. This meant that he didn't just have a book, he had a method. Moreover, he was being given an opportunity to implement the plan in major projects.

FIST, the procedure he developed for developing projects quickly and efficiently requires that things be less physically complex, less cognitively confusing and complicated. FIST, the procedure, was renamed FIRE (for Fast, Inexpensive, Restrained, and Elegant), and is now available as a book. The "S" in FIST became this book: The Simplicity Cycle.

Not surprisingly, the two books support one another. FIRE, the book, offers lessons highly relevant to The Simplicity Cycle. Large projects all tend to fail. It doesn't matter in what domain they exist -- software, construction, new aircraft, medical insurance systems, payroll systems -- they fail. Ward offers a simple solution: don't do them. With the time and money allocated for one large project, do numerous small ones. Do them Fast and Inexpensive, with Restraint and Elegance: FIRE. It's a well-known principle, but it goes against the nature of organizations who wish to solve all their problems with one project. In consumer markets, it encourages the disease I call featuritis. In industry, it's bloat. What's the alternative? FIRE. How do we avoid unneeded complexity and manage to maintain simplicity? That's the focus of The Simplicity Cycle.

The Simplicity Cycle

In The Simplicity Cycle, Ward examines the normal trajectory of the design of systems. Consider how good a system might be, perhaps with some measure of "goodness." Zero complexity also means zero goodness. To increase goodness, complexity must be increased. At some point however, the complexity starts getting in the way, perhaps by making the system far too difficult to design, or to construct, or to manage. Perhaps it is now too difficult to comprehend. Whatever the reason, once past the high point of goodness, increasing complexity decreases goodness. But it is necessary to reach the point of overcomplexity in order to get to the ideal match of complexity and goodness. As Ward puts it:

Patience and diligence are keys to avoiding premature optimization. First, we need to gain the necessary tools, talents, pieces, parts and components... and only then can we apply them in the appropriate degree and trim out the extraneous.But simplifying too soon is just as bad as complexifying for too long.

Ward suggests several ways of reducing unneeded complexity. One is simply to arbitrarily remove components and see how well the system functions. If it still functions well, that component was unnecessary. Keep doing this until as much as possible has been removed while still yielding acceptable goodness. Does this sound too simple? Too obvious? Well, it is still resisted. Ward describes the result this way:

Sadly, some designers seem to believe reducing complexity makes the design worse. ... This position is based on the belief that not only was every additional feature, part and function an improvement, but that the accumulated additions also made things better from a system perspective. Such an assertion is misguided and maybe a little arrogant.Why "arrogant"? Because it assumes everything we ever added was a good idea.Why "maybe"? Because those additions may indeed have been good. But getting rid of them might be even better.

A second method is through restructuring. "A cube is less complex than a collection of squares," he points out, because "it is one object, not six. It is also 'more good' because you can do more with a 3-D object than a 2-D object." This is similar to the transformation of airline cockpits from many separate, physical displays into a smaller number of well-integrated visual displays - what is today called "the glass cockpit." It isn't just a matter of combining things, it required rethinking them, reconceptualizing them. The result was that complexity went down while goodness went up. Similarly, taking six squares and using them to form a cube reconceptualizes it as a new object, where we no longer think of it as having six separate parts but rather as a single, integrated whole. Complexity goes down: goodness goes up.

The two books: The Simplicity Cycle & FIRE

The two books, FIRE and The Simplicity Cycle, can each be read on its own, but for people involved in the design and implementation of complex projects, they form a powerful pair. For anyone wanting to embrace the mantle of simplicity, this book, The Simplicity Cycle, is essential.

Making something simple is difficult. Simplicity is actually quite complex.