The Art of Discovering What We Don't Know: Constraint Discovery in Software Development
Software development's biggest failures stem from critical design decisions being made invisibly by individual developers during implementation, rather than systematically surfacing these constraint discoveries during specification when business context is available and changes are cheap.
Photo Credit: Rob Grzywinski There's a moment in every creative endeavor — whether you're writing a story or building software — when you hit a wall that isn't really a wall at all. It's more like a door you didn't know existed, and behind it lies a choice you didn't know you had to make. In software development, we call this "constraint discovery," though it might be better described as "the moment when the universe forces you to be honest about what you're actually building."
The Discovery Moment
Picture this: You're deep into specifying a system, encoding constraints, trying to nail down exactly what makes something valid or invalid. Everything's going smoothly until suddenly — it isn't. You realize you can't write a unique rule for something that should have a single, clear answer. Multiple valid solutions exist where there should be one. You need optimization criteria where you thought the problem was already defined.This isn't failure. This is discovery.What you've stumbled upon is an irreducible design choice — a fundamental decision that was hiding in the specification, waiting to be found. The beautiful thing is that this breakdown wasn't a problem to solve; it was the system revealing what it actually needed to be complete.
The Hidden Architecture of Every Successful System
Here's what most people don't realize: every "sensible default" in every successful system is evidence that this constraint discovery process already happened. When CSS decides how multiple flex items share available space, that's not arbitrary — someone hit the exact same wall we're describing. They encountered the ambiguity, recognized it as a required design decision, and made an explicit choice that became baked into the standard.The difference is that in most software development, these discoveries happen in the worst possible place: during implementation, under pressure, made by individual developers who may lack business context, documented nowhere, visible to no one.
The Invisible Crisis
Software projects fail at an alarming rate, and here's a hypothesis for why: critical design decisions are being made in private by people who shouldn't be making them, at times when those decisions are most expensive to change.Right now, organizations operate with hidden unknowns — fundamental ambiguities in their specifications that won't surface until someone tries to build the thing. A Product Manager says "build a layout system" and a developer nods and heads off to battle. Somewhere in that battle, the developer realizes that a decision of significant magnitude needs to be made. And here's the crazy part: instead of escalating this decision back up the chain, the developer usually just makes it.The organization then lives with the consequences of a choice they didn't know was being made, by someone who may not have had the full context to make it well.
The Methodology: Systematic Discovery
What if we could surface these decision points during specification rather than implementation? What if we could make the Product Manager encounter the same "oh crap, what do we do here?" moments that successful system designers encountered, but earlier in the process when iteration is cheaper and business context is available?This requires a fundamental shift in how we approach system specification. Instead of trying to describe what we want to build, we relentlessly pursue constraint completeness — we keep encoding what makes something valid until the system breaks down and forces us to confront what we don't know.The methodology has a simple core: exhaustive validation. Every entity must have exactly one value for every required property. When we can't achieve unique values, we've found an under-specification. When we're tempted to add arbitrary defaults, we stop and ask why the situation is ambiguous. When constraints only work in one direction, we're missing something. When dependency cycles emerge, we need explicit decisions to break them.
The Discovery Mindset
The real work happens in our heads as we encode. We ask ourselves:
"Is this relationship fully determined, or could it go multiple ways?"
"Am I making an arbitrary choice here that should be explicit?"
"If I can't write this constraint uniquely, what decision am I avoiding?"
When we get stuck — when we can't write a rule that gives exactly one answer — we stop and surface the discovery: "This specification is incomplete because…" We force a decision, then continue encoding with the new constraint, repeating until no more ambiguities emerge.
From Hidden to Visible
This approach transforms unknowns from hidden to visible and manageable. Instead of "we don't know what we don't know," we get to "we know what we don't know." That's a fundamentally different position. You can plan around known unknowns. You can assign them to the right people. You can iterate on them before they become expensive to change.The goal isn't to solve every problem upfront — it's to make the critical decision points visible early enough that they can be addressed by the right people with the right context.
The Creative Parallel
This mirrors something fundamental about creative work. The best stories aren't the ones where the writer knew everything from the beginning. They're the ones where the writer discovered what the story was really about through the process of writing it. But — and this is crucial — that discovery happened during drafting, not during publication.In software, we want our constraint discoveries to happen during specification, not during implementation. We want to find the doors we didn't know existed while we still have time to choose which ones to open.
The Meta-Insight
Every successful system is evidence that this process works. The question isn't whether constraint discovery happens — it's whether it happens systematically and visibly, or haphazardly and in private. Whether it happens when decisions are cheap to change, or when they're expensive. Whether it happens with full business context, or in the isolation of implementation pressure.The methodology doesn't create new problems. It surfaces problems that were always there, waiting to be discovered. The choice is whether we discover them deliberately or accidentally, early or late, together or alone.And that, perhaps, is the most important constraint discovery of all.
The dirty secret of AI productivity: when you can think at machine speed, your human brain becomes the bottleneck. We've created intelligence abundance only to discover we have no idea how to handle it — and we desperately need new interfaces for thinking with AI rather than just at it.13 June 2025
Surface Tension reveals how problems are solved by pushing against constraints. From coding to creative writing, constraints are the universal pattern underlying all problem-solving and innovation — this is where we make that pattern visible and actionable.22 February 2025
