Resulting is the tendency to equate a decision’s quality with its eventual outcome. A bad result does not necessarily prove that the original decision was bad, just as a good result does not prove the decision was sound. section 9.1.2 section 9.7
Monolith or microservices?
A team chooses a monolithic architecture, then finds two years later that it has become a big ball of mud. Calling the decision bad solely because of that outcome is resulting. The original evaluation should instead consider the context, available information, alternatives, and uncertainty at the time. Hindsight bias can make the outcome seem more predictable than it was; microservices might also have produced a distributed ball of mud. section 9.1.2 section 9.7
Reduce resulting when reviewing a decision by:
- Separate the quality of the decision from the quality of its outcome. section 9.1.2
- Document the alternatives, analysis, context, and reasoning rather than only the selected option. section 9.1.2
- Find one personal or professional example involving a bad outcome and another involving a good outcome. section 9.1.2
