To someone without a lot of big tech experience, this can look like a problem with the codebase. It just seems so awkward and complicated – if it were correctly factored, all of this would be so much easier. But this is an error. First, you’ll never get around the mathematics of adding new features, no matter how nice the code is. Second, big tech codebases are awkward because balancing features is difficult, not the other way around.
And further down:
Much of the complexity is produced by a small set of what I call “wicked features”, which interfere with every other feature. For instance, adding a whole new user type: once you do that, you have to ask “can this user type access this feature” for every feature for the rest of the company’s life.
On a similar note, Catherine Jue:
Companies that do fast very well tend to have very focused products.
This is because the effort to make software fast often requires stripping away non-essential features. Compare how fast a streamlined project management tool like Linear loads versus an enterprise app like Workday (or worse… Oracle). In a world obsessed with adding rather than refining, speed becomes the ultimate expression of respect.
Much like cooking, continuously adding tasty ingredients to a dish won’t necessarily produce a good result. Staying focused — the hard bit of it — is saying no to good ideas.
Even so, I believe a level of complexity remains unavoidable at scale — especially when software attempts to map the messy, unstructured, reality of our world.
The New Yorker, on complex systems:
The boat is hard to alter precisely because it’s sailing; the system is hard to change because it works. This doesn’t mean that we don’t want to change the system—but it does mean that we should interpret its resistance differently, not as a sign of failure but as an indication of usefulness. Repairs are harder mid-voyage. That shouldn’t make you want to burn your boat.