Choosing for Upside vs. Probability in Software Decisions
A basketball analogy for software tradeoffs: sometimes the right engineering decision maximizes upside, and sometimes it maximizes the chance of success.
What can basketball stats teach us about software engineering?
Quite a bit, actually.
Two useful stats are field goal percentage and points per possession.
FG%tells you how often a shot goes in from a certain spot.PPPtells you how much value that shot produces on average.
A three-point shot can have a lower chance of going in than a layup and still be the better choice over time because the payoff is higher when it works.
That is why teams care so much about efficiency.
But context changes the answer
If there are ten seconds left and your team is down by one, the best average shot is not always the best situational shot.
In that moment, you may care less about long-term efficiency and more about raw odds. A simpler, safer shot can be the right call because the goal is not to maximize value across a season. It is to make one basket right now.
That tradeoff shows up in software all the time.
The software version
When things are stable, we can optimize for the long game:
- cleaner abstractions
- better maintainability
- stronger performance characteristics
- tools that help the team move well together
But when production is on fire, or when a short-lived migration script needs to ship today, we may care about something else: the highest chance of a correct result under pressure.
That does not mean standards disappear. It means priorities shift.
The mistake is treating one metric as if it matters in every situation.
Sometimes you want the most efficient move over time. Sometimes you want the move most likely to work right now.
Knowing which game you are in is half the job.