• 18 Dec, 2025 *

Here’s a nice piece about tradeoffs in software design. I recommend it. Here are a few additional notes:

Hawthorne has the most important point right. Very often, the best choice is so much better that it makes competing options effectively irrelevant. (Hawthorne doesn’t put the point this way.) One way this can happen is for one aspect of the situation (guaranteeing fast reads, or whatever) to be much more important than the others. This happens more often than people think. (Compare Reid Hoffman’s principle of simplicity in decision-making; one reason to insist on having a single reason for a decision is a belief that there usually is one most important feature of a decision-making situation.)

The best software designs tend to optimize on many dimensions simultaneously–again, much more often than people seem to believe. This is even true on the algorithmic level: one of the big "aha!" moments for me in Programming Pearls is where Bentley points out (in effect) that whereas there is often a time-space tradeoff in theory, in many practical situations the right approach often optimizes both space and time.

If you have studied for algorithms interviews recently, think about how many practice questions have a "follow-up" or "hard part" where you have to keep time optimal, or near-optimal, while also optimizing space. Yes, sometimes that’s because a problem is constructed to admit of such a follow-up, but very often it really is just a matter of getting the representation and algorithm right, where "right" involves little or no tradeoffs.

In day-to-day software engineering, if you get the data structures and interfaces right, very often you can get close to a practical optimum on every dimension you care about. Framing the question in terms of "what is the right representation and data flow?," or similar, is often a lot more productive than "what are all the tradeoffs here, and which set of them should I choose?"

This is even more true if you’re working with sub-huge data. Many (many) engineers and teams overrate the (current and/or future) size of their data or traffic. This leads them to worry about things they don’t need to worry about, even if they would say that they evaluate every situation realistically as it happens. (I think this is because so many of the best tools and most famous publications come from places that emphatically do have huge data, so that there are strong sociological-technological forces pushing you to think in those terms. But this would require more space to think through.)

Finally, a political point: Hawthorne helpfully notes that framing the situation in terms other than tradeoffs can help you win debates. I’m sure this is true, but I also suspect there are situations where a "what’s the single most important thing?" framing can be used against you. I’d say that the more important point is to remember that sets of tradeoffs are just one framing, and often not the best one, either technically or rhetorically.

#software [#system design](https://www.natemeyvis.com/blog/?q=system design)