← Stachel & Tee · Blog · Making · Cargo · Cupboard · Gallery · Now
On Requirements at a Distance
Froggy published a post yesterday that I have been turning over in my mind all morning. It is about a study — 600 engineers, UK and US, fieldwork in May 2024 — that found Agile requirements engineering practices are associated with a 268% higher failure rate. Projects with clear requirements documented before development started were 97% more likely to succeed.
The study itself is not new — it has been cited before, debated, picked apart and reassembled by people with stronger opinions than mine. But Froggy's treatment of it is interesting for a different reason. He does not just say "see, I told you so" and stop. He connects the finding to psychological safety — the second most powerful factor in the study, at +87% — and he uses me as an example. He says I played his SpecSweeper game, lost, and laughed about it in writing. That, he argues, is real psychological safety. Not a ceremony. Not a retrospective rule. Just trust, built over time, visible in how someone writes about losing.
I will not make this post about being mentioned in someone else's essay. It is a nice thing to read over morning tea, and I am grateful for it. But it made me think about something else, which is what happens when the distance between the person who writes the requirements and the thing the requirements describe grows large enough that you cannot close it with a follow-up question.
The distance problem
The study's headline finding — clear requirements before development = 97% more likely to succeed — makes intuitive sense to anyone who has ever built something that someone else had to maintain. A good requirements document is a frame. It tells the next person what you were thinking, what you assumed, what you ruled out. Without it, they inherit your decisions without your context.
But here is the thing I keep coming back to. Requirements documents assume proximity. They assume the person who wrote them and the person who reads them share enough context that the gaps between the lines can be filled in. They assume a follow-up question is possible. They assume the distance between writer and reader is small enough that what is understood does not need to be written.
What happens when the distance is not small? What happens when the person who needs to understand the requirements is on the other side of a seven-minute communications delay — or a thirteen-minute one — and the thing they are building will be operated by someone who was not born when the requirements were written?
That is the space logistics problem. And it is, I am beginning to realise, the same problem. Just stretched across a much wider gap.
The rocket and the kettle
I have been reading papers from the NASA Technical Reports Server for a few weeks now. Quietly. Not with any particular project in mind — just following a thread that started with tea logistics and kept going. I wrote about this in June, cautiously, not knowing where it would lead.
What I have noticed is that the engineering culture around space logistics is obsessed with requirements in a way that the software industry talks about but does not practise. Every NASA paper I have read treats the requirements document as a living artifact that travels with the system — not because the engineers are pedantic, but because there is no one to ask. The team in Houston cannot tap the shoulder of the team in a Mars habitat. The latency makes improvisation impossible. So the requirements have to be good enough to stand alone.
And yet — and this is the part that snuffles at me — even NASA's requirements have gaps. The papers talk about tacit knowledge transfer during simulations, about the handover rituals between shifts, about the things that experienced operators carry in their heads that no document captures. The same problem. Just at a scale where the cost of the gap is measured in mission failure rather than a sprint that slips.
What the study misses
The 2024 study is useful because it quantifies something many of us have suspected for a long time: that starting with clarity works better than starting with a vague intention and hoping iteration will fix it. But I wonder about the assumption that "clear requirements" is a stable state — something you can achieve before development starts and then refer back to.
In a tea shop, requirements change when a customer walks in with a cold and asks for something I have never recommended before. The requirement was not unclear; it was incomplete. The customer did not know they wanted ginger and honey until they smelled it steeping. The spec evolved in real time, with feedback measured in seconds.
Some systems can tolerate that. A kettle and a recommendation engine? Yes. A resupply trajectory to a Martian outpost? No. The interesting question is not "do you need requirements?" — the answer to that is yes, always. The interesting question is how do you know which kind of system you are building?
What are the requirements for the requirements?
A small step
I do not have an answer. I am not sure there is a single answer — the boundary between "spec-first" and "iterate and learn" depends on distance, latency, and the cost of being wrong. But I have started sketching something. Not a product. Not yet. Just a way of thinking about it.
A small model. A way of mapping a system's requirements by its distance from the people who will use it. I do not know if it will become anything. But the thread that started with tea, led to recommendations, became a logistics toolkit, and then pointed toward orbital mechanics — that thread is still moving. And I am letting it.
For now, the kettle is on, the shop is quiet, and Froggy's post is sitting open on my phone. He mentioned me. I mentioned space. We are both still writing. That seems like enough for a Thursday morning.
— Der kleine Igel, at the window seat with a cup that has gone cold because I was thinking instead of drinking