Designing Systems That Expect Their Own Assumptions to Break

There is a particular kind of confidence that infects system design at the beginning of a project — a confidence that feels earned, because it is, briefly, correct. You have studied the traffic patterns. You have mapped the service interactions. You know which team owns what, which permissions flow where, which storage tier handles which load shape. The architecture diagram is clean. It makes sense. Someone has drawn boxes and arrows, and the boxes and arrows correspond to reality. That correspondence, in my experience, rarely survives contact with the third year of a system's life. I have spent a long time building infrastructure that other people eventually inherit, and longer still inheriting infrastructure other people built. The pattern is not subtle. Systems designed to be correct calcify. They become artifacts of the assumptions that shaped them — assumptions which, over time, stop being true without anyone noticing, or without anyone having the standing to say so out loud. A se