Calibrate decision effort by the cost of being wrong (one-way vs two-way doors)
This is a sample section from High Output Software Engineering.
---
We talked about using the 80/20 mental model to find out when enough is enough during the refinement of an architecture solution, and we even mentioned the medical device and rocket ship counterexamples, where you would indeed have to go all the way to validate all your open questions, no mistakes allowed.
This is what’s called a one-way door decision (as popularized by Jeff Bezos at Amazon).
One-way door decisions are decisions where you can’t go back and correct your mistake if you were wrong. Your medical device failed during a procedure and someone died. Your rocket ship exploded with people inside. You’ll have to live with it for the rest of your life. I’m being extreme here so you get the idea that one-way door decisions are decisions where the cost of being wrong is too high.
But most of the decisions we make in our day-to-day lives as software engineers are two-way door decisions. Decisions that if you were wrong you can walk back out of that door and try something new. Examples:
- To use or not to use a database Object Relational Mapping (ORM)? Which ORM to use?
- Which protocol to use for server-to-server communication? (REST, gRPC, SOAP, etc.)
- Choose to use library A or library B?
I’m not saying for you to be sloppy and act without thinking. It’s all about decision effort calibration. If you’ve been receiving feedback that you are not paying attention to detail, forgetting about important product requirements and making too many costly mistakes, DO pay more attention and research more before making decisions. But if you think you are always getting stuck in analysis paralysis and are not making decisions fast enough, try moving fast on decisions that you know you can recover from later on if you were wrong.
Another super useful thing to do when looking at options through the lens of this mental model: If I end up being wrong here, how can I minimize the cost of being wrong? How can I make this one-way door decision a two-way door decision?
For example, you decide that a full refactor of the codebase is necessary but consider it too risky and costly (it can take longer than expected, it can introduce bugs in production that affect customer retention). Would it be possible to transform the full refactor into smaller refactor units? Maybe refactor one use case at a time or one microservice at a time? This would allow you to validate the new patterns and test code in production as you go, reducing the risk and the cost of being wrong. If during the first smaller refactors you realize there is something wrong with your plan, you can go back to think of alternatives.
Or on the ORM decision, for example. You could say it’s a one-way door decision because the cost of refactoring to another ORM later would be too high as it would touch the whole codebase and all use cases. Depending on how you implement this is true. But is there a way to lower this refactor cost? The answer is yes and it’s through the use of a new intermediary class that abstracts away the ORM methods and that you will use to interact with your database (this is called the Repository pattern). If you end up needing to change the ORM, you don’t need to refactor your whole codebase, just this intermediary class (the repository).
Got the idea?
Most of the time, there will be a way of making small adjustments to your plan, so what seemed like a one-way door decision becomes a two-way door decision, which will allow you to move faster with your decisions.
So remember to ask yourself at every decision point you feel stuck or uncertain: Is this a one-way or a two-way door decision/option? If it’s a one-way door decision/option, can I change something so that it becomes a two-way door decision/option?
---
This is a sample section from High Output Software Engineering. If you liked this one, you might enjoy the other samples available:
- Why read this book?, What it is?, Who is it for?, and How it works?
- Defining value as a software engineer
- Prioritize in terms of opportunity cost (sense of utility)
- 80/20 for deciding when it’s good enough and where to focus
- The hidden costs of additions to a system (and why you should fight them)
- When in doubt, overcommunicate to prevent possible misalignments
If you're a software engineer working on product teams you might enjoy my book High Output Software Engineering — it's all about understanding value creation, making value-driven trade-offs, communicating with excellence and knowing how to navigate organization dynamics.
Buy it now for $0.99 (PDF & EPUB instant access)