A decision that seemed settled has to be reopened, so a product leader explains the intent again. Engineers search old tickets, tests, and code to determine what a rule was supposed to mean. Architects reconcile locally sensible implementations that do not behave the same, and the people who remember how everything fits together are pulled into another meeting.
None of this necessarily looks like failure. It is often how organizations keep work moving. But together, these activities reveal a hidden operating cost: people repeatedly have to reconstruct what the product is supposed to do, why that behavior matters, and what the next change must preserve.
That repeated reconstruction is the visible pattern at the center of The Gap. Its effects appear under familiar names. Delivery slows down. Costs rise. Technical debt accumulates. Requirements appear to grow after implementation begins. Defects surface in software, dependencies disrupt delivery, and inconsistent behavior appears across products, platforms, and channels. Capable teams spend more time clarifying, coordinating, and correcting, while a few experienced people become increasingly difficult to work without.
Because these effects appear in different places, they are commonly diagnosed and treated separately. Organizations respond with better planning, refinement, requirements, architecture, engineering, testing, automation, coordination, operating models, or another transformation. Agile, Lean, Scrum, DevOps, and related practices have produced real improvements. Yet an organization can become better at planning, building, testing, releasing, and coordinating software while still depending on reconstruction to make the next change possible.
Reconstruction is not the root cause. It is what people are forced to do when the delivery system cannot carry a connected understanding forward as work moves and new understanding emerges. That understanding includes what the business is trying to accomplish, how the software is intended to behave, what was actually built, why important decisions were made, and what later work can safely rely on.
Roadmaps, features, work items, conversations, designs, code, tests, approvals, support procedures, and personal memory can each preserve part of that understanding. Each also serves a narrower purpose. When the delivery system has no persistent structure for keeping those parts coherent as work moves and understanding changes, later teams have to reconstruct enough of the whole to proceed.
The problem is not simply that information is scattered or documentation is incomplete. A new repository can gather more material, but it cannot by itself keep the product coherent as discoveries surface, decisions are made, implementation changes, and responsibility moves between people. Repeated reconstruction consumes time, coordination, judgment, trust, and delivery capacity. Different teams can also reconstruct the same product differently, which is how locally sensible decisions begin to diverge.
The Gap follows that reconstruction burden back to the deeper structural causes and asks what a software delivery system would need to contain, govern, and preserve if future work were no longer expected to rebuild what the organization had already paid to learn. The answer it develops rests on roughly fifteen years of observation, application, failure, adjustment, and further application across real software-development environments.
This is not a book about fixing Agile, writing better tickets, or building a larger documentation repository. Nor does it claim that uncertainty can be eliminated before development begins. It asks how discovery can remain part of software development without allowing each discovery to become an invisible product decision in code, tests, workarounds, or the memory of whoever happened to be present.
The book also gives readers a practical place to begin. By the time many software initiatives reach delivery, they have taken the form of requests: add a feature, change a rule, produce a report, integrate a system, support a new channel, or create a new product. The Gap examines what happens when those requests are converted into work, what can be lost in that transition, and why the consequences often appear only after implementation is underway.
The stakes are rising because AI can turn unresolved assumptions into working software faster than ever before, while regulators, auditors, customers, security teams, and leaders are demanding stronger explanations of what software does, why it does it, and why the organization considers that behavior acceptable.
The Gap is written for product and engineering leaders, architects, principal engineers, system stewards, executives, transformation leaders, and experienced practitioners who have seen these problems return despite serious efforts to address them. It will help readers recognize when their organization is paying the cost of reconstruction, distinguish symptom relief from root-cause correction, and judge whether a proposed improvement reduces the need to rebuild understanding or merely helps people cope with that need.
The point is not to document everything, but to make product change possible without repeatedly paying to reconstruct the meaning future work depends on.
