A look at system design through the lens of human activity
As a kid, I would hang out at the restaurant my dad managed, watching in wonder as the tickets move through their lifecycles: jotted on a notepad, entered in a computer, printed in the kitchen, served, and finally, spiked.
Things got interesting if there were pantry or raw bar elements, where tickets would split, then converge before serving. Dishes could have parts with different cook speeds; the timing blew my mind.
A typical dinner shift radiated a sense of choreography, of intertwined concerns and responsibilities playing out across time. Information flowed to the relevant people and stations, guiding their contributions, shaping meals that moments before were figments of hungry imaginations.
Food for Thought
As a software author, my style is indelibly colored with this metaphor. Often I find myself imagining code as people, wondering what conversations they would have, what slips of paper would pass between them, what machines they would use. It brings motion to a domain, at a familiar scale.
A clear theme in these musings is relevance. Who needs to know what, when? This question focuses not on the shape of data, but its points of contact. Answers describe scenarios, not schemas. Data takes on a situational feel, separate from the individuals that use it.
Through this lens, data has less influence on design. Time emerges as an organizing force, orienting data around workers and the decisions they make. Whereas a data model describes a system at rest, a timeline describes activity.
Make It So
A decision introduces information into the world. “I’ll have a sandwich”, once uttered, starts a process that will (most likely) result in receiving a sandwich. The world moves to a state including my order: I wait, while the order goes from the server’s pad to a ticket on the line.
If someone asked for an order now, I would say “nothing”, aware of my prior decision. I have an internal model of the situation, from my perspective. If it takes a while, or I receive soup, I might decide to say something. If I get the expected sandwich, I’m no longer waiting and can dig in.
Paying the check concludes the meal. The decisions and their data, so recently relevant, fade to historical record. More meals will happen, even at my same table, but this particular one is in the books — no more decisions to make.
Data Has No Base
The meal was a process, a series of decisions, each building on the outcomes of those before. Had I opted for pasta, the world would be a different place (ever so slightly). The server, the kitchen, and I each had internal models guiding our participation, with similar concepts but from various frames of reference.
This relativity of data frees design from the monolithic database. What once was a central representation of a system’s knowledge, breaks out into a collection of perspectives, each with a finely-tuned model specific to its concerns. I am not aware of my sandwich’s journey through the kitchen, only that I ordered, waited, and received it. My parts of the process determine the relevance and shape of the data that interests me.
This data accumulates locally, influencing my future decisions. There are no concurrency/consistency mishaps, as the model is exclusively mine. I tend a boundary in which knowledge grows.
Honesty Club
We often hear that software mimics the real world, and to that I ask: does it? Do these principles of collaboration underpin our experiences? Are processes, decisions, and localized data our design primitives?
Not so much. I am accustomed to applications whose navigation is a set of nouns, inviting me to arrange them for use by processes shrouded in mystery. I am left to construct my own understanding of them, often leading to incorrect expectations, frustration, and resentment.
This is part of why contemporary software doesn’t feel quite “right”. It is rooted in a spatial metaphor, an anachronism from the days of cramped CPUs. In today’s distributed, collaborative, reactive world, when is more important than where.
To Go
I think back to the restaurant, to its dance of action and reaction, and consider how people have been organizing like this long before electricity gave us computers. They are simply the latest (greatest) method to connect with others and work toward goals together. We instinctively understand how knowledge work works; it’s time we started building like it.
Thanks for reading — I leave you with my favorite quote:
Computer science is no more about computers than astronomy is about telescopes. — Edsger Dijkstra
Top comments (0)