I have used the following principles to help with decision making on projects:
1. Be mindful of one-way doors
In his letter to Amazon shareholders[1], Jeff Bezos talks about the concept of one-way and two-way doors:
Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.
I find the above quote really fascinating since it provides a solid framework for decision making that is applicable to all parts of life. Let’s see how we can apply this when making engineering decisions in projects.
Imagine we are building a new product whose features have some overlap with an existing product. As an engineer, you need to determine if it makes sense to build the infrastructure for this new product from scratch or if there is value in re-using the infrastructure from the existing product. The answer is not obvious since it depends on the state of existing infrastructure (how much can be re-used, how easy it is to extend to support new-use cases, how reliable it is etc) and other product considerations. After looking at all the variables, you might end up in a state where there is no clear answer. So, when there are no clear answers and we need to make a decision with incomplete information (about the future), the above principle comes handy.
If you build on top of the existing infrastructure, what is the cost of reversing the decision? If you build completely new infrastructure, what is the cost of reversing the decision?
If we determine that for one of the options, the cost to reverse is not high, then we don’t need to agonize over getting this decision right. This might sound strange but we are essentially optimizing for the failure scenario by managing risk. This also has the benefit of reducing sunk cost since you can pull the plug any time.
Being aware of this principle gives us another advantage. Now that we know that it is better to make reversible decisions, we can make conscious choices that allow us to convert seemingly one-way doors to two-way doors. In the above example, one could argue that building on top of existing infrastructure is a one-way door since some of the underlying data stores need to be significantly modified to support old and new use-cases. But you could spend some additional effort to build a layer of abstraction to keep the data stores separate so that it is easier to go back in time if needed. So, always think about the nature of the decision when making them and avoid one-way doors as much as possible.
2. Focus on simplicity
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall
What is a simple system? I define a simple system as follows:
A simple system is one whose design makes another engineer think “That’s it? I could have built this easily!”
Simple systems make life easier for engineers maintaining them and building on top of them. Most engineers want to build simple systems. But very few manage to do that. Here are some reasons why:
- Keeping things simple (or avoiding complexity) is never an explicit goal
- Requirements change over time requiring systems to add more features to support them
- Increase in system complexity is hard to measure when making a series of seemingly simple small changes to the system
So, how can we build and maintain simple systems? Here are some principles:
- Be wary of introducing new use-cases which theoretically could be supported by this system but not something the system was designed for. It might make sense to build something separate than to make changes to the existing system. Although it might seem like more effort to build a separate system, it is important to factor in maintenance burden of building on top of the existing system.
- Maintain “separation of concerns” when building systems i.e. modularize the system so that each module does one thing only with clear interfaces and minimal interaction with other parts of the system.
- Optimize for the most common use-cases. I have seen engineers fall into the trap of building a system that handles every single edge-case including really rare ones. This usually leads to a lot of complexity. It is better to build the system for the common use-cases and then handle the rare cases through separate mechanisms like one-off scripts etc.
- Push back on new requirements unless there is sufficient value to adding it.
Engineers have a huge role in determining the outcome of most projects. It is not always easy to know what the right decision is in the middle of a project. It usually comes down to the judgement of individuals/group of individuals. So it is important for engineers to have good guiding principles to help them make these decisions.