“Analyzing the Decision Criteria of Software Developers Based on Prospect Theory” by Kina et al *applies behavioral economics to a question that I’ve spent a lot of time thinking about: *what makes developers adopt software and methodologies which will aid them in their jobs?
The premise of the paper is that there are some things, like basic static analysis and model diagramming, that pretty much everyone should use in some form or another when writing and designing software, so it’s interesting to think about why not everyone does. In other words: What prevents some software developers from adopting basic tools which have been well-established as beneficial, almost necessary?
The questionnaire from “Analyzing the Decision Criteria of Software Developers Based on Prospect Theory”
In order to answer this question, the researchers set out to determine if developers exhibit specific types of biases in their evaluation processes when choosing to adopt tools, and how this might impact their decisions. They gathered responses to the questionnaire above, designing the questionnaire to test the presence or absence of two specific types of bias:
-
The certainty effect: “people make a decision, considering not only the expected profit, but also the certainty”
-
The ambiguity aversion: people choose uncertainty over ambiguity, e.g. favoring A3–1 below:
A3–1. A jar which includes 50 red balls and 50 black balls. A3–2. A jar which includes red balls and black balls. The total number of balls is 100, and the number of red balls and black balls are unknown.
They findings of the paper are very interesting. First, there’s a point that is pretty obvious to anyone who has worked at a software company before:
Developers do not always act to maximize expected profit because of the certainty effect.
In other words, maximizing profit takes a back seat to certainty in the selection process for software development tools. More on the biases exhibited by developers in this position:
Developers avoid selecting tools if the probability of the effect of the tools is unknown, and the tools have some risks. This result suggests that it is not easy to apply new tools to actual software development projects since the probability of the effect is generally unknown before the application. To promote development support tools, we have to suppress the risk of the tools.
For me, this paper raises some fundamental questions:
-
If you make a tool for developers, what does “risk” mean in the context of your tool?
-
How can you mitigate this risk for your users?
-
If you can only mitigate so much, how can you communicate clearly about the tradeoffs involved in adopting your tool?
While the sample size of the study could have been larger and some of the ideas more deeply explored, for me, this paper helped emphasize an intuition I’ve had for a while now: Studying how risk plays into the decision making of potential customers is crucial for technical products.