Anti-tradeoffs
Engineering is full of tradeoffs.
Rust is more performant than Python but also more complex.
A large language model is more powerful than a small, special-purpose one but costs more to host and run.
A single-page application (SPA) has nicer interactivity than a static website but has longer load times and is harder to maintain.
This is so pervasive that we often assume tradeoffs even in cases where there are none. For example:
Quality vs Speed
Writing shoddy software is faster than writing good software. At first. There comes a point, very soon, where the poorly constructed code will slow down any future development. A great article exploring this in more depth can be found here. The only way to go sustainably fast for a long period is to invest in quality. Good design, frequent refactoring, and solid test coverage. As the Navy SEALS say, "Slow is smooth and smooth is fast".
Speed vs Stability
Just as rushing the development process in hopes of gaining speed is doomed to fail, so is throttling the release process in hopes of guaranteeing quality. Here's a quote from Luca Rossi's Substack newsletter, Refactoring:
The counterintuitive truth is that, in software, there is no trade-off between speed and stability.
In fact, speed creates a virtuous cycle:
Fast releases → allow for frequent releases
Frequent releases → allow for small releases
Small + fast releases → create lower risk and faster recovery from mistakes.
Team Size vs Impact
Adding manpower to a late software project makes it later. — Brook's Law
The reasons cited for this (slightly simplified) law are
Communication overhead
Ramp up time
Indivisibility of many tasks
The converse of the law, then, is that small teams can deliver faster and with higher impact than large teams because they avoid overhead, hand-overs, and coordination as long as they actually possess the capabilities required by the project.
Many large companies have realized this and shifted their organization to loosely coupled groups of small, competent teams, with OpenAI among them.
Final thoughts
There are bound to be many more such anti-tradeoffs in the world, where common wisdom or first appearances suggest a tradeoff when, in reality, there exists synergy. In other instances, we could engineer things to transform a tradeoff into a synergy. A quick example that comes to mind is that a password manager enhances both security and convenience. The next time you face an either-or decision, consider why it can't be both!
