How Cognitive Biases Affect our Software Architectures • Birgitta Böckeler • YOW! 2022

It's note For architects, which addressed the following biases that are important to us when designing software:

• Confirmation biases People subconsciously work with information to confirm their point of view. This results in people having difficulty accepting change and being prone to repeating their previous decisions and actions. That’s why it’s often so difficult for us to change established development processes or solution architectures – usually requiring a change management workshop. I have often encountered this bias in others and caught it in myself.
• Zero risk bias This bias affects how people manage risk. Often there is a desire to eliminate a small risk completely, rather than mitigate the overall risk by even a large amount. This refers to security risks, avoidance of vendor lock in, or the presence of premature optimizations that can protect us from scaling risks, but are often not useful in the end, and are expensive. This bias can be circumvented if you have a risk framework and use it in your projects.
• Availability heuristics This bias is about making quick, but sometimes not the right decisions. And we build our conclusions on the available information. In software development, for example, this is manifested in the fact that tech debt is often forgotten, since it is clearly not fixed and it seems to be absent:) Therefore, it is worth going from the opposite – to make sure that information about important things is easily accessible. In software development, this is relatively easy to do using logs, metrics, and trading for both technical systems and development processes themselves.
• Base rate fallacy This bias affects how we estimate the probability of different scenarios, and then how we allocate the strength of our teams. Often we focus more on edge cases, which we know a lot about, to the detriment of some more general scenarios. This bias affects the prioritization of efforts, so it’s cool if you have +/- standard metrics to evaluate and compare the importance of tasks with each other.
• Outcome bias This bias is about people evaluating decisions based on results. We have the saying “winners are not judged” and that’s what it is. But it is much more productive to change the approach to assessing the decision, focusing on the information that was available at the time of the decision. In development, this approach is used when using RFC writing processes. (request for comments) ADR (architecture decision records). This allows you to assess the quality of decisions after the fact, and not just start from the results.
• Self-serving bias This bias is that people tend to attribute success to their abilities and efforts, and failure to external factors. It also affects how we evaluate our decisions. And this bias prevents us from growing above ourselves, because we withdraw our growth points from our control zone by appealing to blind chance. It is much more constructive to follow the proverb “learn from mistakes”.

P.S. Report continues well post forward Sunk cost fallacy (Non-recoverable costs)

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership