tradeoffs
- 2 minutes read - 334 wordsLife is (just) a series of tradeoffs.
- DawnAnn “Mom” Johnson
I heard this so many times growing up that I think I actually stopped hearing it. But recently, I realized that it’s never been more pertinent than to my current day-to-day life as a software engineer.
The fundamental tradeoff we make on the Risk Systems team is trading off between
- how much fraud we catch (and symmetrically, miss!)
- how many false positives we incur to catch that much fraud
Those false positives running rampant can inhibit growth (in terms of interested customers) of the product we’re trying to protect, but letting too much fraud through can make a product too expensive (and even liable to be shut down!)
These consequences are pretty dire, but any project with a machine learning underpinning – and especially those with an adversarial aspect! – probably finds itself in a similar standoff.
A level below that, there’s a more detailed level of distributed systems tradeoffs, like: If our datastore is unavailable, would we rather
- be unavailable, and perhaps not respond to some client?
- be available, but permit our own records to be lossy?
Another level even further below that, there’s tradeoffs around how to spend the team’s time! Should we
- attempt to overengineer a bulletproof, multi-datacenter, cloud-native solution, but risk never finishing it?
- ship the smallest thing that could possibly work, and risk having to throw it away later?
There’s an interesting meta-tradeoff here, which is: Should we
- expend extra effort into not committing to a given path? (ie: hedge)
- not bother, paying that cost later if we need to? (ie: gamble)
I don’t have answers for any of these, really. Every option I’ve listed has been the perfect answer for some project and the death knell for another.
And I think that was always Mom’s point: It’s just a tradeoff! So
- be aware of and open to the opposite approach
- be mindful of the tradeoff you’re making
- be on the lookout for times to seek a different tradeoff