uml

What should code look like when we squint at it?

It’s the start of another school year, and my seventh-grade son is learning algebra. As I sat beside him to coach him through some homework the other night, I shared my favorite bit of wisdom about how to make math problems—even complex ones—simple and error-free:

Write the progression from known to unknown, one step at a time.

In my experience, the surest recipe for disaster is to short-circuit this rule. Collapse a few steps in your head in the name of efficiency, and you’ll forget a minus sign, or you’ll group incorrectly, or you’ll lose track of an exponent or an absolute value—and you’ll end up with a mess. You’ll have to debug your solution by slogging back through the problem from the beginning until you figure out where you went wrong.

It’s interesting—and maybe, profound—how nicely this piece of advice maps onto the design principle of progressive disclosure. The human mind is simply wired to perceive in broad outlines, and then to gradually clarify, a few details at a time.

Don’t believe me? Try a short experiment: draw this fractal.

Fractals embody the principle of progressive disclosure. Image credit: Fábio Pinheiro (Flickr).

I’ll bet that instead of laying down every pixel, like a printer, you immediately produce a simplification that captures the general shape as lines, with a lot of detail suppressed. You did this as a kid, when you drew stick figures and triangle+half-circle sailboats.

Artists sometimes squint to blur out what they don’t want to see, leaving only general patterns and colors. But coders never do, because we don’t expect code to work that way. Continue reading →

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 →

Role-Play Centered Design

User-centered design (UCD) is important. I hope I’ve been a good advocate for it during my career. Its basic tenet is that software should be constructed as much as possible according to how users think and work, not according to techie considerations. (A seminal book on this topic is The Design of Everyday Things, by Donald Norman.) At its best, UCD promotes an alignment between technology and customer pain points that keeps software’s value proposition compelling. Even on a bad day, UCD makes software a lot more pleasant to use.

However, UCD rarely yields all potential benefits, which is why I’d like to suggest a specialized form of UCD for many software teams. I’ll dub this idea “Role-Play Centered Design” (RPCD, prounounced /ˈrɪpˌsɪd/) because of the way the various parts of the system come to life. (This idea is similar to–though conceived independently from–the concepts in this article from the proceedings of HCI ’07.)

Role plays can help you build software — not just entertain. Photo credit: TheArches (Flickr)

Manifesto

RPCD is distinguished from ordinary UCD by three key tenets.

  1. The “system” includes people.
  2. Specifics are non-negotiable.
  3. The best way to understand is to “be” the system.

Let me justify each of these ideas, and then I’ll give an example of an RPCD process at work.

The “system” includes people.

Most architectural and UML diagrams focus on software and/or hardware entities. The user’s role in the system is implicit. Even among users of activity diagrams, most workflow is computer rather than human.

This is wrong. software – people != software. Any thoughtful veteran of the industry can tell you stories about why this is so. Engineers who accept the flawed premise that only the computer side of software needs to be designed are already handicapping their UCD fatally. The system built by a software team includes people — individual users, a community, support personnel, sales folks, professional services, maintainers of docs on a web site, etc. If you let an engineer construct “the system” with no serious thought to the people, you often end up with misalignments that make it irritating to understand/use/configure/support, expensive to maintain, or even impossible to sell.

Specifics are non-negotiable.

The devil really is in the details, and if you don’t solve detailed problems, you won’t solve problems at all. The design of a system is therefore best driven by specifics–even if the specifics are only postulated. Specifics are best exemplified by use cases, and role playing forces specifics into use cases.

The best way to understand is to “be” the system.

You should “be” the software in the system, and you should “be” the people as well.

When a human being actually interviews someone in the same way an automated wizard eventually will, you learn things. The human reorders the questions or short-circuits part of the interview because she knows it’s unnecessary. Or the human gets frustrated at how needlessly cumbersome a particular part of the process is. Or the human asks some intelligent questions that you never considered. When two humans interact to model what’s eventually going to be a formal protocol, you confront asynchronicity and error handling in ways that UML or whiteboards don’t.

Modeling the system in role plays also has some other profound long-term advantages that go far beyond just what you learn. I’ll discuss these in a different post.

In my next post, I’ll give an example about how RPCD works.

Action Item

List all the people that interact with or help create your software. If your list has less than four or five unique roles, think some more. Hint: see this post.