System Design

There’s a temptation, when you’re building software for large organizations, to let the complexity of the customer’s world bleed into the complexity of what you build. The customer has ten business units with different billing requirements. The customer has regulatory constraints that vary by geography. The customer has legacy systems that need to connect to your new thing in ways that weren’t designed to work together. All of this is real. All of it creates pressure to build something that accommodates every edge case, every workflow variation, every exception to the rule. ...

There’s a conversation I’ve had more times than I can count, and it usually starts the same way. An engineering leader — smart, experienced, under pressure — says something like: “We need to move faster. What can we do right now?” And the honest answer, the one that actually matters, is almost always: “It depends on what you built three years ago.” Business agility is mostly an architectural property. Not entirely — teams, culture, and incentives all matter — but the ceiling on how fast you can move is often set by decisions that happened before the current pressure existed. This is uncomfortable to say because it implies that the answer to “why are we slow now?” is partially “because of choices we made when things were fine.” But it’s true, and pretending otherwise doesn’t help anyone. ...