Software Tradeoffs

Originally published on lavkesh.com

Every design decision you make closes off something else, which is just how software works, so making tradeoffs consciously is key, rather than doing it accidentally by adding features that increase complexity or optimizing for performance in a way that adds latency

The tradeoff between functionality and performance is a common one, where implementing a feature in a clean and expressive way may make it slow, or making it fast may result in code that's hard to read, and the answer depends on what matters for your specific case

If the code runs once a day in a batch process, optimizing for readability makes sense, but if it's in a hot path that runs thousands of times per request, optimizing for performance is the way to go, and applying the same answer everywhere is a mistake

I learned the hard way that guessing latency is a recipe for late‑night fire drills. On a payment‑gateway service handling about 5 million requests a day, we added a micro‑optimisation to a JSON serializer that saved a few microseconds on paper, but the change introduced a memory leak that grew the heap by 300 MB after a few hours. We caught it only after pulling a heap dump and running a flamegraph with Pyroscope; the profiler showed the hot path was actually dominated by network I/O, not serialization. The lesson was to instrument first, use eBPF tracing or a low‑overhead profiler, and only then decide whether the code path deserves a rewrite.

Flexibility versus simplicity is another big tradeoff, where building an abstraction to handle many scenarios may make the code harder to reason about, and the right approach is to write the simplest thing that works but structure it to be easy to extend if needed

Scalability versus cost is also important, where designing for current traffic and optimizing cost may require a painful rewrite later, and measuring growth rate and runway is crucial to making the right decision, such as if you're growing 20% month-over-month and only have capital for six months

Security versus usability is a constant tradeoff, where requiring multi-factor authentication and hardware keys may make the user experience pristine but also cumbersome, and most of the time the right answer is reasonably secure, not maximally secure

When we rolled out mandatory hardware tokens for an internal admin console, the login success rate dropped from 98 % to 84 % overnight. The support tickets spiked, and a critical incident at 02:30 am was caused by a senior engineer locked out of the system. We responded by adding a push‑based second factor that leveraged the company‑issued mobile app; the conversion recovered to 96 % and the incident count fell dramatically. The numbers taught me that a 10 % drop in usability can translate to several hours of lost engineering time each week, so I always benchmark the user impact before hardening a flow.

To make these decisions, be explicit about what you're optimizing for, understand the costs, measure instead of guessing, and iterate, starting with the simple solution and optimizing as needed, and document the decision and reasoning for future engineers

Technical debt and long-term thinking are also crucial, where taking a shortcut that makes the code harder to understand may cost you every time someone works on it, and thinking about the cost of getting it wrong and how likely it is can help make the right decision

In one legacy service we inherited, the test coverage was under 30 % and the codebase was peppered with global state. We introduced a gradual refactor strategy: first we added contract tests with Pact, then we isolated side effects behind interfaces and used SonarQube to track code smells. Over six months we lifted coverage to 78 % and reduced the mean time to resolve a bug from 4 days to 1.2 days. The key was to treat the refactor as a series of small, shipping‑ready changes rather than a big rewrite that would have required a full outage.

Sometimes compromise is necessary, and getting specific about what matters most, such as optimizing for readability in one service and for throughput in another, and documenting the decision and reasoning is essential for future engineers to understand and change the tradeoff if needed

Treating tradeoffs as permanent is a mistake, and revisiting the decision periodically and measuring to see if what you optimized for still matters is crucial, and having a strategy and being intentional about tradeoffs is key to avoiding a system that's mediocre at everything