Book Review: Universal Principles of Design

I’ve always thought of Software Design and Software Architecture as different from other design disciplines. After all, building a house is way different then constructing software. And I also read a lot of books on Software Architecture, and in these books, the authors often point out the differences, such as:

- We have only been building software for fifty years but we have been building houses for several thousands of years.

- Software is more malleable and can be modified easier than a building.

- Design patterns for software don’t look much like design patterns in other disciplines.

And yet I have discovered a book about design that applies to software in a big way. It is title Universal Principles of Design, by Lidwell, Holden, and Butler. This book contains 216 design principles, with each described on a few pages or less, with diagrams and quotes from other sources for each principle. The book is brilliant.

Here are some of my favorite principles that I use in my work:

The 80/20 Rule

“A high percentage of effects in any large system are caused by a low percentage of variables”.

There are many examples you probably heard about with this rule. Some listed in the book are:

- 80 percent of the town’s traffic is on 20 percent of its roads

- 80 percent of a company’s revenue comes from 20 percent of its products

And my favorite:

- 80 percent of a product’s usage comes from 20 percent of its features.

What if we could focus our efforts only on that 20 percent of the features? Productivity and success will follow.

Another favorite:

Mental Model

“People understand and interact with systems and environments based on mental representations developed from experience”.

A great example of this given in the book is the interaction with ABS brakes. With a conventional braking system, the drier should pump brakes on a wet slick surface, but with ABS brakes, the car will properly stop and make a turn when slamming or steering while braking. If you are a driving used to conventional brakes, you may not understand this when using ABS brakes.

The book says that designers often have accurate system models but inaccurate user interaction models. Users have accurate user interaction models but inaccurate systems models. Designers need to obtain user interaction models to create designs. They can obtain this by testing and interacting with their designs as users. One of my goals in the next year is to be a tester for all my designs.

And my favorite so far is:

Ockam’s Razor

“Given a choice between functionality equivalent designs, the simplest design should be selected.”

A great example of this is the Google search interface. Nothing could be simpler and it continues as the main interface to the search engine.

Another application is with interfaces. When I design interfaces I strive to make the fewest methods possible. It is a struggle to do this but each method is carefully evaluated.

I plan to read and reflect on a principle a day with this book and will blog on other principles in the future. I feel like I found a treasure cove of ideas for my daily work.

Less Is More

I discovered this web site completely dedicated to Agile Software Architecture. In fact, when I search the web I can’t find anyone that thinks that Software Architecture is dead or gone with the Agile Software movement. For once, the world agrees with me.

The web site outlines what we would like to achieve with Agile Software Architecture:

1. Deliver working solutions
2. Maximize stakeholder value
3. Find solutions which meet the goals of all stakeholders
4. Enable the next effort
5. Manage change and complexity

In my experience the first objective is the most important. I have always wanted to deliver a working solution as soon as possible to test out the ideas of the architecture. In fact, I often work on the implementation before the architecture is completely documented or modeled.

The web site also lays out a set of principles that align with the Agile Manifesto but are specific to architecture:

1. Value People
2. Communicate!
3. Less is More
4. Embrace Change: Plan It, Manage It!
5. Choose the Right Solution for the Enterprise
6. Deliver Quality
7. Model and Document in an Agile Fashion

My favorite of these is #3, Less is More. In my work, I consider the expense of everything. I once had a colleague who was a master requirements writer. She wrote hundreds of requirements for each feature where I would write about a dozen or two for similarly sized features. From my experience, each requirement had a high cost. A test was created for each requirement on each of our product platforms. If that requirement failed, error reports would be generated. If the requirement was truly necessary, then these things (tests, error reports) were indeed necessary. But what I found was when there were too many requirements, very few people would read them and thus their usefulness went downhill.

With documentation and requirements, I like to use advice that Robert C. Martin gave at a seminar I attended: “Rip content out until it hurts!”. After all, you can always put it back in.