A psychology of bug fixing

Dealing with bugs is an integral part of the everyday life of software engineers. Over the time software engineers integrated a lot of practices in the software development process to avoid bugs or to detect them as early as possible. Pair programming, code reviews and automated tests running on the build pipeline are some of those practices.


Even though software engineering companies adopted a lot of those practices, the delivery of 100% bug free software can’t be guaranteed all the time.

One option to deal with bugs is to adopt a zero bug policy. That means if bugs were detected they get the highest priority and developers have to stop doing what they are doing and have to focus on the bugs. In the real word this approach might be problematic because of delivery pressure and the aim to hit the sprint target.

Considering these aspects, bugs have to be prioritized according their impact, so that the ones with the biggest business impact have to be fixed first.

When prioritizing bugs there are two important categories of impact. The first category is money loss. For example, when the “purchase now” button is not working. In this case it is obvious to handle the bugs that cause the biggest loss first.

The second category is the annoyance or “pain” caused from the bug when using the product. For example, if the images of an article are not sharp as usual. Also in this case bugs with the most pain should be fixed first. Really? But wait. Evaluating pain by human is not that obvious and often affected from the irrational part of our brain. Here is where psychology and brain research can help us with the evaluation of bugs according the pain they cause.

Duration neglect

Duration neglect is the psychological observation that people’s judgments of the unpleasantness of painful experiences depend very little on the duration of those experiences. Multiple experiments have found that these judgments tend to be affected by two factors: how the experience felt at its peak (when it was the most painful) and at its end. Hence, the term “peak–end rule” describes this process of evaluation [1][2].

In one study, Daniel Kahneman and Barbara Fredrickson with other collaborators had subjects place their hands in painfully cold water. Under one set of instructions, they had to keep their hand in the water for an additional 30 seconds as the water was slowly heated to a warmer but still uncomfortably cold level, and under another set of instructions they were to remove their hand immediately. Otherwise, both experiences were the same. Most subjects chose to repeat the longer experience. Subjects apparently judged the experience according to the peak–end rule (in other words, according to its worst and final moments only), paying little attention to duration [3]. In other words subjects preferred more pain to less which is irrational.

Now let’s come back to our bug evaluation. Imagine we can give bugs a “pain score” measured with “pain units” PUs.

Consider we have a bug A that occurs once a day and has a pain score of 1 PU and a bug B that occurs once a week and has a pain score of 3 PUs. Collecting the pain points of both bugs over a month, bug A has 30 PUs and bug B has 12 PUs. Even though bug A causes more collective pain as bug B, according to the peak-end rule, bug B has to be addressed first.

The tricky part of the story is how to determine the pain score of a bug. There are a bunch of tools that could help us to find out the PUs of bugs. A one star rating on the App Store means more PUs as a two star one. If your software product has a public issue tracking system, you may ask the issue reporter to give a “pain score”. Also a smart tracking system in your application which is able to analyse user behavior when a bug arises might help in this case.

End of the Session

According the peak-end rule bugs that occurs at the end of the user session also have more negative impact and should be targeted first.

It is a great benefit if your tracking system is able to track the end of the user session and determine the exit screens of your application.

On the exit points of your application, not only bugs should be strongly avoided but also every annoying event like advertisements and surveys should be avoided or at least minimized. Following this rule could positively affect the user’s pain memory associated with your application.

Generalisation: Pain memory and user retention

User retention is one of the main metrics of software products based on web pages or mobile apps. It means: Make users come back to your product and prevent them to go to your competition.

To increase user retention, software products have to positively influence the pain/pleasantness memory of their users. Psychological observations like duration neglect and peak-end rule could help product managers to optimize their products to achieve this purpose.


[1] Ronald Ross Watson; Colin R. Martin (15 April 2011). Handbook of Behavior, Food and Nutrition. Springer. p. 669. ISBN 978-0-387-92271-3. Retrieved 6 September 2013

[2] Keith J. Holyoak; Robert G. Morrison (18 April 2005). The Cambridge Handbook of Thinking and Reasoning. Cambridge University Press. pp. 284–. ISBN 978-0-521-82417-0.

[3] Kahneman, Daniel; Barbara L. Fredrickson; Charles A. Schreiber; Donald A. Redelmeier (1993). “When More Pain Is Preferred to Less: Adding a Better End”. Psychological Science 4 (6): 401–405. doi:10.1111/j.1467-9280.1993.tb00589.x

Image: https://pixabay.com/en/face-silhouette-brain-communication-535767/

Leave a Reply

Your email address will not be published. Required fields are marked *