Software development
Implementing what the architecture defined, without losing the thread between blueprint and code.
Between the blueprint and the code, the thread is lost.
The architecture defined one thing and something else got built. Not out of bad faith: because whoever wrote the code was not in the conversation where the reasoning was settled, and at the first doubt chose what was reasonable instead of what was agreed.
How we avoid it.
Continuity is not documentation. It is the same people carrying a decision from the blueprint through to production.
- 01The why travels with the what — Every architectural decision reaches the team with its reasoning and the alternative that was rejected. A requirement with no why is reinterpreted within a week.
- 02Built on data that is already governed — We do not invent a new model for this one application. If the data is not governed, that is what has to be solved first, and we say so.
- 03Releases that can be operated — With traceability, versioned migrations and a way back. A deployment only its author knows how to run is not finished.
What is left at the end.
A system your own team can maintain, and the reasoning behind each decision written where someone will look for it. The alternative is dependency, and dependency is paid for at the next procurement.