I was planning to build a tiny storage shed for my small backyard. Part of me wanted to jump in and start framing right away, but lumber is expensive and I could imagine wasting it.
Being wood, the structure could easily become too heavy to move. I might need access to the wall behind it, so I wanted to keep the framing minimal. But then it also needed to support the roof load from snowfall.
Drafting plans revealed other unexpected details. How much space 2x4 studs would make the shed take up. How to have enough roof overhang without adding too much weight. If I’d done much construction before, these likely would have been trivial details, but I hadn’t.
As much as I could measure over and over, getting into the drafts exposed key details I’d otherwise miss. Working with it revealed what I needed to know but couldn’t see before.
Back to the future
This is not at all a new insight for any of us. Donald Schön wrote about this more than 40 years ago in The Reflective Practitioner. In one chapter, he takes us through a conversation between an architectural design instructor and a student planning an elementary school. Schön depicts dialog and sketches as they work through the challenge. They use phrasing and vocabulary specific to their discipline, loading terms with meaning relevant to the problem at hand. The student, Petra, identifies the choices and constraints she finds most troublesome.
Quist, her mentor, is wrestling too with the problem. He tries and abandons more typical techniques for less conventional ones, devising metaphors for them to explore. They relax architectural prescriptions to fit a situation best practices didn’t foresee. As they talk, Petra finds she can’t quite express the conceptual challenges she perceives designing for the site terrain. As they go, it becomes clear they’re iterating through different framings. They “begin with a discipline” and then “break it open” to find more fitting solutions.
They highlight different aspects and consequences, common vocabulary emerging throughout the conversation. They play with tradeoffs, abandoning some as interesting but flawed. They discover how those impact the hoped for functionality of the school building. Exploring the building site, choice by choice.
Thus the designer evaluates his moves in a threefold way: in terms of… consequences judged…from the normative design domains, in terms of their conformity to or violation of implications set up by earlier moves, and in terms of [their] appreciation of the new problems or potentials they have created.
A conversation arises between the original challenge, options tried, and the outcomes proven to be important. The situation talks to them, they talk back, and so forth. It proceeds until the situation and a solution find common ground with one another.
Schön also points out that an experienced professional like Quist can’t capture everything they know into words. They have to demonstrate it to help lift out the tacit knowledge and intuition. It’s like breathing: it’s easy until you focus on it (great, now I’m suffocating). It’s not his thinking lacks rigor as much as he’s so practiced that nuance is now implicit. It wasn’t for him when he started and it isn’t yet for Petra.
Chatterbox or black box
As professionals who create software, we too work through this with each other and with our tools. We often recognize patterns we can apply and tradeoffs from our choices, but encounter details that demand more from us.
We regularly hold conversations with the situations we’re asked to develop software for. We struggle to articulate to those who weren’t there with us how we found it. We collaborate to load terms with our colleagues, stakeholders, and users. Those not present may miss language we shared and details we discovered.
It’s why we follow agile processes. Being agile isn’t necessarily faster, it’s not necessarily cheaper, but it reduces risk. We learn or confirm in each iteration what will help us be successful going forward. We engage with the details, letting them influence and inform us as we mold and shape them.
As software professionals, we’re first and foremost conversationalists with situations. We must engage with the problems we face to see how choices can fit together. Our solutions don’t need to be perfect. They need to reflect the tradeoffs accepted for the obstacles exposed. And we need to bring along those who weren’t part of our conversation to appreciate our choices.