Software Requirements and Hindsight Bias

You know about hindsight bias, right? It’s when your mind distorts memories to bring them in line with your current thinking, or current events. If you’ve ever heard someone say they “knew it would happen all along” maybe they did, or maybe it is just hindsight bias at work. In one of the first studies published on hindsight bias researchers Fischhoff and Beyth asked students about to rate the likelyhood of 15 different possible events occurring in the then-upcoming visit of U.S. President Nixon to China and the USSR 1972. Students were then quizzed 2 weeks and 6 months after the visit, and asked to recall their earlier predictions. Three quarters of the students remembered assigning higher probabilities than they actually had to events they thought had happened, while the majority remembered assigning lower probabilities to events they thought had not.

And Software Requirements

What does this have to with software requirements? Well, I don’t know about you but I’ve seen lots of instances where stakeholders have transitioned, when presented with a question about system behaviour, from “I don’t understand what you mean” to “I have no preference either way” to “I want it to do X” to finally “I’ve always wanted it to do X”. It doesn’t take long for hindsight bias to kick in, and the stakeholder really believes they’ve always wanted “X”. When this happens when talking about a system on a whiteboard, or roughing out a flow-chart on a scrap of paper then all is well. When it happens during software construction it can usually be remedied. When it happens at the end of a build phase you’d better hope you’re working in some kind of iterative process, or else that stakeholder is going to be pissed. After all, you’ve failed to deliver feature “X” which they’d asked for “from the very beginning”. The benefits of iterative processes are that they allow you discover the features the stakeholders have recently come to believe they’ve always been asking for.

And Risk

The implications of hindsight bias to risks on software projects are (ironically) predictable. Risk that become issues always seem more predictable in hindsight. The benefits of a formal risk process where people meet and assign probabilities and impacts to risks is as much to get people thinking about risks as it is to have a record of what probabilities people actually thought at the time, and not what they remember they thought.

And Technology Choices

Over the longer term hindsight bias affects our judgement regarding different technology industry trends. Of course the rise of mobile computing was entirely predictable in 2007. The internet bubble of the 2000’s - how could people be so stupid? And front-end package management frameworks in 2016? everyone thought that was a bad idea at the time.

Thanks to hindsight bias, all of these implications of hindsight bias to software development will seem “obvious” and things you’ve “known all along”.

Photo Credit Oscar Anton

Software Developer, Brisbane, Australia