This post is part of my sporadic Notes to a Young Software Engineer series.
For budding software engineers, the most critical mindset shift is to view most engineering decisions as tradeoffs — not as good choices versus bad choices.
This can be challenging, as the more prevalent mindset in our society is good and evil. The latest Marvel superhero movie pits the good superheroes against the bad. A politician decries the opposing side as the devil, while extolling what she can do. On Hacker News, the software engineer sees a new framework or database as the ultimate solution to current problems.
This manichaean mindset is so popular partly because great storytelling leans so heavily on the good and evil framing. As such, the engaging stories that sell in our society — on social media, in movie theaters, in newspapers1, and yes, at engineering meetups — come to rely on this framing.2
There are very few silver bullets for becoming a better software engineer, but I’ll argue that learning to view most decisions as tradeoffs, not good versus bad, is the top one.
Partisans and Good versus Bad
As a software engineer, many of the people you’ll be exposed to — including fellow software engineers — won’t use the tradeoff framing.
Partisans, those who benefit from a technology choice, will rarely talk in tradeoffs. A whole host of those in technology are partisans: the creator of a tool, the owner of a cryptocurrency token, a consultant pitching their services, a venture capitalist who funds new technology, a teacher who sells a technology training course.
Dev tool marketers and sales people will favor pitching their tools as good and the competing alternatives as bad. Any developer who favors their own tools — an open source developer, a developer advocating for their favored tool at a company — will also often fall victim to this framing.
Partisans see the alternative as terrible. For most of us though, when faced with two competing alternatives, we’ll benefit most from seeing the tradeoffs between them, and choosing the best one for our needs.
Vue is one of the few teams that’s written a comparison in a way that seeks to highlight the tradeoffs:
We also try very hard to avoid bias. As the core team, we obviously like Vue a lot. There are some problems we think it solves better than anything else out there. If we didn’t believe that, we wouldn’t be working on it. We do want to be fair and accurate though. Where other libraries offer significant advantages, such as React’s vast ecosystem of alternative renderers or Knockout’s browser support back to IE6, we try to list these as well.
Vue’s attitude hits a few critical notes of the tradeoff framing: noting limitations in their own technology, proactively noting the benefits of competing technology, and having the humility to note their biases. Compare their perspective, to the “cons” on this post on Elixir.
When circumstances change, we’ll also need to change our mindset. A nascent database (like MongoDB) may be a bad choice for a company, but once it has matured, the choice should be revisited.
New versus old
In software engineering, the most common way to see the good and evil framing is in new versus old.
Early in your career, you’ll often use popular Hacker News headlines to determine what tools to use. Many of these posts are due to unfounded hype. Posts will be written by allies who value the advantages so much, that they’ll ignore the downsides. New tools also have greater marketing budgets than old tools.The more appropriate RTJ mindset, is overwhelmed by easy tropes that see new technologies as silver bullets.
It’s also clear what the downsides of old tools are, but the issues with new tools are still not known (see Chesterton’s Fence). The proponents of new tools also primarily highlight its positives. This sets up an impossible comparison.
With any new tool, the tradeoff framing will help you better identify potential disadvantages.
The Tradeoff Framing
It’s valuable to know how to create a tradeoff framing.
A tradeoff framing is constructed in the following way:
X has these advantages, BUT has these disadvantages … In the context Z, X is likely a good choice.
The tradeoffs framing does four main things for a specific tool or choice:
- Notes the advantages
- Highlights the disadvantages
- Visualizes a context in which the tool makes sense
- Notes key areas of uncertainty (when relevant)
In the context of tools, software engineers have a shorthand for remembering the tradeoff framing: the right tool for the job. RTJ, the common shorthand, aims to make the proposed tool — and the excitement around using it — subservient to the needs of the job at hand.
In many engineering debates, say a debate in the comments on Hacker News, proponents of a technology choice will rarely give context into their use case or background. Without this information it is impossible to make a good choice.
For example, for databases, the right database choice requires understanding the context in which it needs to be be used. Will it be used at a hackathon, at a startup, in high volume data engineering, in a Fortune 500 company at worldwide scale?
To compare, let’s look at a number of recent software engineering debates in both framings:
| Topic | Good/Bad Framing | Tradeoff Framing |
|---|---|---|
| MongoDB | MongoDB is the future of databases, with infinite scale and easy usability. The majority of application software that developers write will be in use cases that are better fits for MongoDB and other NoSQL technology. We’re living in the post-transactional future. | In 2012, MongoDB is effective for unstructured data, but doesn’t make sense for most forms of structured data. It is also difficult to manage given how new it is. |
| Elixir | I’ve had nothing but fun with the [Elixir] language and the platform. And the Phoenix Framework is just icing on the cake. I would not start another (side or production) project with anything else than Elixir. | Look at the problem you are trying to solve. In Elixir, you get the power of multi core and support for distributed computing out of the box. If you need multi core support and your team is composed of Rubyists, Elixir can be a good choice. |
The Project Management Triangle is another famous example of the tradeoff framing in practice, with cost, time, and features weighed against each other:
Software-engineers need to make tradeoffs every day on topics far beyond tool comparisons: short-term benefit versus long-term benefit, value to me versus value to team, value to engineering versus value to our users, value to more QA versus value to marking a story done.
Engineering tradeoffs exist not just on the technical level (“what framework lets us create the most appropriate technical system today”), but also on the non-technical plane (“what framework lets us hire great engineers and maintain it”).
A valuable exercise is to identify what type of framing is used in a technology post or argument and — when it is in good versus evil — reassess it in the tradeoff framing.
The Tradeoffs of Tradeoffs
The tradeoff framing shouldn’t be seen as a silver bullet. The beauty of thinking in tradeoffs is that it is self-referential: tradeoff framing itself has tradeoffs.
The tradeoffs mindset isn’t an excuse to defer critical decisions. Poorly applied, though, it can lead to this. Seeing the downsides of both sides can lead to decision paralysis. In actuality, tradeoff framing should simply provide a new lens through which to view options before making critical decisions.
Early adopters also don’t see the world in tradeoffs. If you were attracted to Rails in the mid 2000s or cryptocurrencies in the early 2010s, you were so enraptured with its benefits that it outweighed every issue (and early in a technology’s lifecycle, there are many issues). Tradeoff framing means that you might miss some critical trends, or at least have trouble joining early in a new technology’s lifecycle.
On some issues, tradeoff framing totally fails. It can be just one dangerous leap to go from “democracy has its downsides” to Nazism has its plusses.
Tradeoffs have tradeoffs, but they also provide tremendous value.
This post is part of the Notes to a Young Software Engineer series.
- For example, the war in Yemen isn’t well covered in US papers partially because the lack of clear cut good vs bad guys means it isn’t more engaging for a US audience. As a New York Times reporter notes, “Conflicts [like the war in Yemen] gain sustained American attention only when they provide a compelling story line … most of all … good guys and bad guys.” ↩
- For example, an early critique of JR Tolkien’s Lord of the Rings noted just how many of his characters fit this trope, though he disagreed citing characters like Saruman. ↩