Module 99: Technology Governance
Reviews and decision records
🏠The everyday picture
A building's plans are checked by a structural engineer before construction, and the reasons for unusual choices are written on the drawings. Years later, when someone wants to knock down a wall, they can see why it was there.
📘What it really is
- Several kinds of review keep quality and knowledge flowing:
- code review on every change (Module 78), focused on correctness, security, clarity and fit with the design;
- design review before significant work: a short design document (problem, options, proposal, risks; Module 91) read and discussed by others; much cheaper than reworking code;
- architecture review periodically: does the system still fit its requirements and growth? Where are the biggest risks?
- security and privacy reviews for sensitive features (Modules 79 and 80);
-
post-incident reviews (Module 72).
-
Good review culture:
- review the work, not the person; be kind and specific; explain why;
- the author asks for the kind of feedback they need; reviewers separate must-fix issues from suggestions;
- reviews happen quickly (within a day), or they block flow (Module 98);
-
decisions don't need everyone's agreement, but they need a clear owner and recorded reasons.
-
Architecture Decision Records (Module 91) become the system's memory:
- one short file per significant decision, numbered, in the repository (
docs/adr/); - status (proposed, accepted, superseded by ADR-012);
-
never deleted; superseded when decisions change, so the history stays readable.
-
Lightweight governance: a regular (monthly) technical review where the team looks at ADRs proposed, the debt register, dependency updates, incidents and costs.
🖱️Try it
Create a docs/adr/ folder for the booking platform with your existing ADRs numbered and in a standard template, and write one new
ADR superseding an earlier decision (for example, moving reminders from in-process to a queue). Write a short design document for one
upcoming feature (group sessions), and review it against a checklist: requirements, options, data changes, security, privacy,
migration, rollout, monitoring.
✅Quick check
Why review a design before writing code?
Show the answer
Problems found in a document are much cheaper to fix than problems found in built code.
Why are old ADRs superseded rather than deleted?
Show the answer
So the history of decisions, and the reasons for them, stays available.