On adding bandaids
— 2 min read
We use our past performances to create a prediction of an outcome and take a decision. We make errors, lot of them. We form a picture in our head of a possible result and then, reality kicks-in.
Even when we postpone to the last responsible moment, delaying commitment and keeping important decisions open until the cost of not making a decision becomes greater than the cost of making a decision, we still make errors.
When starting a new feature, it's important to make a list of possible things that may go wrong and rate them on probability and impact scale.
This can lead to adding buffers, "just in case", "to be prepared for the worst". They may look useful at first, a cushion to fall when things go unexpected, but they come at their cost.
We are having the impression of having managed the risk, when in reality the risk is still there, no real action has been taken to mitigate it. The risk has just been converted into a higher cost of the functionality, to handle the case if the risk manifests.
Constantly adding bandaids leads to worse outcomes, we think that the risk is managed and focus on the next decision and when things go "unexpected" we put a bigger patch for the future.
What is needed, is to address risks with high probability and impact with concrete actions like:
- spikes to see if a technical solution is viable
- demos to the customer to gather feedbacks on tricky parts
- slice features and address one category of users at a time
It is easier? No. Will it eliminate all risks? Also no. But constantly trying to anticipate a risk will give us more context. Knowing what made an impact and reuse it for future choices will bring benefits of performance and agility in decisions. The constant addition of patches instead, will lead to stiffening our organization to the point of slowly taking us out of the market.