Why Long-Lived Codebases Need Patient Architecture
Cathedrals are built stone by stone — so are repos that last a decade.
[ essay ]
Demo code optimizes for Thursday. Long-lived code optimizes for the engineer who arrives in year three.
Patient architecture invests in boundaries: modules with contracts, tests at the seams, docs for the failure that will happen after the original authors leave. I accepted a slower essay-index change on mystic-bytes so the next collection would not inherit another one-off Liquid path. Feature one cost more. Feature ten will cost less. That is the trade.
Every commit stays after the team that wrote it is gone. Ask whether this change belongs in the wall or is rubble someone else will have to haul. They optimize for the demo because demos have dates. Repos that last a decade have a different clock, and that clock punishes clever shortcuts that looked cheap in week one.
Build for the person who has no oral history. Names, tests, and recovery notes are how you leave them a map instead of a legend they have to reconstruct from blame. Teams leave. Commits stay. That is the only audience that cannot be rescheduled.
Prefer the cheaper tenth change over the impressive first one. That is patience, not delay.
— JV · Dark Heart Labs.