---
title: A Conversation With The Situation
teaser: My situation disagreed.
tags: process,velocity,ai,artificial intelligence
author: Richard Newman
published_on: 2026-05-08
---

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](https://thoughtbot.com/blog/illusion-of-fluency).
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](https://archive.org/details/reflectivepracti0000scho).
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](https://thoughtbot.com/blog/the-pace-of-feedback),
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.