design

Book Review: Universal Principles of Design

A few months back, my friend Trev recommended this book to me. I’ve been digesting it one topic at a time, on my lunch breaks.

It is profound and fascinating reading.

This is not another software pattern book. In fact, it is not really software-centric at all. It describes truths about the way human beings perceive, reason, generalize, and communicate. Many of them have obvious application to UX, UI design, and to software in general. On the scale of profundity, it gets a 9 out of 10; I suspect that I’ll be blogging about insights from the book for months to come.

I think it’s important to look at familiar problems from new angles; many profound breakthroughs in science are attributable to cross-disciplinary insight. Though time spent in this book won’t directly hone your coding skills, it will help you see recurring problems and solutions with new eyes, and it will suggest tried-and-true criteria for evaluating design alternatives.

As a teaser, some of my favorite design principles in the book include: Interference Effects, Contour Bias, Horror Vacui, Uncanny Valley, Recognition Over Recall, Wabi Sabi, Satisficing, and Propositional Density.

For now, I’ll omit any definition of what these intriguing terms mean, and leave discovery as an exercise for the reader. :-)

Related articles

The Scaling Fallacy

If X works for 1 ___ [minute | user | computer | customer | …], then 100X ought to work for 100, right? And 1000X for 1000?

Sorry, Charlie. No dice.

One of my favorite books, Universal Principles of Design, includes a fascinating discussion of our tendency to succumb to scaling fallacies. The book makes its case using the strength of ants and winged flight as examples.

Have you ever heard that an ant can lift many times its own weight–and that if that if one were the size of a human, it could hoist a car over its head with ease? The first part of that assertion is true, but the conclusion folks draw is completely bogus. Exoskeletons cease to be a viable structure on which to anchor muscle and tissue at sizes much smaller than your average grown-up; the strength-to-weight ratio just isn’t good enough. Chitin is only about as tough as fingernails.

Tough little bugger — but not an olympic champion at human scale. Image credit: D.A.Otee (Flickr)

I’d long understood the flaws in the big-ant-lifting-cars idea, but the flight example from the book was virgin territory for me.

Humans are familiar with birds and insects that fly. We know they have wings that beat the air. We naively assume that at much larger and much smaller scales, the same principles apply. But it turns out Continue reading →

All I Really Need To Know I Didn’t Learn In Compugarten

I’m glad newly minted software engineers are exposed to data structures, compilers, concurrency, graph theory, assembly language, and the other goodies that constitute a computer science curriculum. All that stuff is important.

But it’s not enough.

Not all classroom material for CS folks should be technical. Photo credit: uniinnsbruck (Flickr).

Since I’m half way to curmudgeon-hood, I frequently find myself lamenting educational blindspots in the young. I’ve even toyed with the idea of teaching at the nearest university, some day when I Have More Time™. If academia would take me, my lesson plans might cover some of the following topics:

Big Data In Motion

I’ve been at Cloud Expo this week, listening to lots of industry hoopla about building cloud-centric apps, managing clouds, purchasing hardware for clouds, buying private clouds from public cloud providers, and so forth.

Photo credit: aquababe (Flickr)

One interesting decision made by the organizers of the conference was to bring “big data” under the same conference umbrella. There’s a whole track here about big data, and it gets mentioned in almost every presentation.

And I’ve sensed a shift in the wind.

Years and months ago, “big data” was all about mining assets in a data warehouse. You accumulated your big data over time. It sat in a big archive, and you planned to analyze it. You spun up hadoop or used some other map-reduce-style tool to crunch for days or weeks until you achieved some analytical goal.

What I’m hearing now is an acknowledgement that an important use case for big data–perhaps the most important use case–has little to do with data at rest. Instead, it recognizes that you’ll never have time to go back and sift through a vast archive; you have to notice trends by analyzing data as it streams past and disappears into the bit bucket. The data is still big, but the bigness has more to do with volume/throughput, and less to do with cumulative size.

This has interesting implications. Algorithms that were written on the assumption that you can corral the data set under analysis need to be replaced by ones based on statistical sampling; exactness needs to give way to fuzziness.

Interestingly, I think this will make computer-driven data analysis much more similar to the way humans process information. As I’ve said elsewhere, when faced with a difficult design problem, a smart question to ask is: how does Mother Nature solve it?

Related articles

Baby Steps

Film poster, displayed under fair use as documented on Wikimedia Commons.

If you’ve seen the delightful comedy movie, What About Bob?, you are no doubt smiling at my title.

Bob is a neurotic and thoroughly irritating patient who depends on his psychotherapist for lots of emotional strokes and life coaching. He ingratiates himself with the therapist’s family and gets himself invited to be their guest on a weekend getaway, against the protests of the therapist. He then proceeds to drive the therapist crazy.

One of Bob’s favorite phrases is “baby steps,” which captures the therapist’s advice to solve problems a little bit at a time, rather than in overwhelming chunks.

“Baby steps” is surprisingly good advice for many questions in software design. It doesn’t apply in all cases, but it applies far more often than it ends up being used.

The Purpose of Design

We create UML diagrams, personas, design docs, lo-fi mockups, and other artifacts to capture our architectural thinking because they provide us with a roadmap of sorts. We need to identify and steer to a consistent point of the compass if we want to produce complex artifacts that meet customer needs. The bigger and more diversified our teams get, and the more moving parts we’re orchestrating into our software, the more important this is.

However, all of these artifacts are means to an end. To whit: Continue reading →