Founding story
The agreement was real. The understanding was not.
Reality Driven Development came from a recurring delivery failure: teams approved software before anyone had experienced the interpretation they were approving.
The meeting ended well. The scope looked reasonable. The estimate seemed defensible. Weeks later, the first real behavior appeared and the room changed. Operations meant one thing. Finance meant another. Engineering had inherited the difference.
The moment kept repeating
The pattern was not dramatic at first. It looked like normal delivery: workshops, notes, requirements, diagrams, estimates, approvals, and a room full of people who believed they were aligned.
Then software behaved. A claim moved to the wrong approval stage. A dashboard no one needed became a requirement. A role was missing. A field that seemed manual was actually derived from another system. A process that sounded universal split between business units.
These were not coding surprises. They were understanding surprises. They had existed during the meeting, but only as private interpretations inside different heads.
The largest risks were often not hidden in the code. They were hidden inside agreement.
Thirty years made the pattern hard to ignore
RDD was shaped by Dan Lichtenfeld's more than 30 years in software delivery, most recently leading IdeoDigital, and by the pressure of real custom software work: portals, workflows, enterprise applications, integrations, modernization programs, and client commitments.
The same failure survived many better processes. Waterfall promised control. Agile promised adaptation. Design thinking promised empathy. Lean promised learning. DevOps promised flow. Low-code promised speed. Each wave helped. None removed the cost of approving imagined software.
For a service provider, this was not academic. Weak alignment became scope friction. Unclear intent became engineering pressure. Shallow discovery became rework. The relationship paid in trust.
The old constraint was rational
This was not incompetence. It was economics. For most of software history, describing a future system was much cheaper than building a realistic version of it. Documents, diagrams, workshops, backlogs, and estimates were rational responses to that constraint.
The industry always knew early feedback mattered. The expensive part was creating enough behavior for the feedback to be meaningful, then changing it repeatedly while stakeholders discovered what they actually meant.
The old process was not foolish. It was built around a constraint that is now moving.
AI made a different question practical
AI did not magically solve delivery. It did something more specific: it compressed the cost of building credible executable interpretations. A team can now materialize a workflow, revise it during the conversation, and let the people responsible for the business react before production commitment hardens.
That opened the question RDD is built around: what if teams could put a working interpretation in front of stakeholders before asking engineering to absorb the ambiguity?
RDD is the discipline that follows from that question. Build enough to understand. Capture the evidence. Freeze only what survived contact with reality. Then engineer what you understand.
RDD is a refusal to let production engineering become the place where hidden intent finally becomes visible.
Return to the argument
The origin is useful only if it helps practitioners recognize the moment before it becomes expensive.