A Game Of Lists

My late friend Bill Rotsler was a moderately famous science fiction author, cartoonist and all-around bon vivant. One thing I remember about Bill is that he loved to play what he called “the list game”. The list game was a collaborative exercise in brainstorming. Often during conversation he would whip out a little notepad that he always carried with him, and ask people to help him come up with lists of things.

“How many like-able villains can you think of?” he would ask, and as people offered suggestions he would enthusiastically write them down. Or he might challenge you with a question such as “How many books can you name where the narrator takes a sarcastic tone?”. Or “how many different animal species have been made into cartoon characters?”

It occurred to me recently is that one of the attributes of being a great software architect is being good at playing the list game.

Imagine you’ve been asked to add a feature to an application that let’s the user delete something — say a file. That seems pretty simple, right? I mean you just call some operating system function and it’s gone, right?

Except things are never that simple. Imagine the following edge cases:

• What if the user changes their mind?
• What if the user wants to delete a whole bunch of files?
• What if the file is owned by some other user?
• What if the files are being referenced by some other data?
• What if there’s an error and the delete operation fails?

Time and time again I see the same pattern played out in software engineering: a customer comes to me with a request that, on the surface, seems deceptively simple. And I take a look at the request and immediately realize that there’s a large number of possibilities that haven’t been considered.

My co-worker Isaac Stone says “engineers and product people tend to implement the ‘happy path’ and call it ‘done’.” By ‘happy path’ he means the path where everything works correctly in the scenario that the user envisioned. It’s the path where we stand on an aircraft carrier with a giant banner that says ‘MISSION ACCOMPLISHED’.

But in real life things often don’t turn out that way, because the world is much more complicated than it is in our imagination.

I often wonder why some people are really skilled at this and other reasonably intelligent people don’t seem to be able to do it at all. Is it some innate talent? Or is it part of one’s training as an engineer? Is it acquired over years of experience? Maybe a little of each? I’m not sure.

But I do think it’s a skill related to the game of lists — the game where you try and think of every possible example given a set of parameters. But in this case, it’s not enough to collect a large number of examples — you want the list to be exhaustive. A big list is no good if it only covers half the cases, whereas a small list is fine if it covers all the possibilities that you care about.

What are some strategies for coming up with a good list? Well, one way is to start with a bigger list and whittle it down. Want to name all animals that have been made into cartoon characters? Well, you can start with the list of all animals — that at least gives you an upper bound.

What if you don’t have a bigger list handy? Well, you can sometimes use a mental algorithm to generate a list of permutations. For example, suppose you want to write a test plan for a web page. What kind of things should you test?

Well, you can start by looking at all of the visual elements on the page. Each of those elements is either interactive or non-interactive. Ones that are interactive respond to a limited number of gestures — left click, right click, shift click, key press, and so on. And each of those interactive elements may be enabled or disabled based on some state in the application. Run through all of the possible permutations of that set, throw out the ones that don’t make sense, and that gives you a pretty sizable list. Of course, it doesn’t cover everything, but at least it’s a start.

One area where the list game is particularly critical is in task planning. Often we want to know how long it’s going to take to build something, which means making a list of all the steps required in its construction. And this is going to require some degree of imagination, because we can’t simply look up the list in a standard reference work. It’s not like building tract houses — there’s no point in writing the same exact program that someone else has already written.

So we have to play the game of lists to get our tasks, and the more comprehensive that list is the better our time estimate is going to be. Fortunately, we can draw on prior experience for some things — we know, for example, that any web app is going to need a view system, client state management, authentication, a network layer, and so on.

Still, in 40 years of professional programming, I don’t think I’ve ever seen a task breakdown or project plan that was 100% complete — there’s always a task or a detail that we forgot or didn’t anticipate.