Behavioral Software Engineering

According to the traditional economic theory, markets are fully efficient and humans operate in them in a rational way. In the late 70s Daniel Kahneman and Amos Tversky started disproving this efficient markets hypothesis, contrasting the consistently logical Homo Economicus (Econ) they depicted, with the more realistic Human who takes decisions based on his questionable points of view. Doing so they gave birth to the study of the psychological factors involved in the making of these decisions, called Behavioral Economics.

The same flawed reasoning also impacts other fields like software engineering: we cannot behave as cold Econ when spending or investing our money, or as rational Engeen when coding. We are humans and this inevitably influences our choices.

The anchoring effect and the availability bias affect how we benchmark and evaluate the performances of our programs. The pro-innovation and bandwagon biases drive our technical decisions, making us to blindly follow hypes and gurus. The not-invented-here syndrome pushes us to create homemade tools instead of using de-facto standards. The framing effect makes us solving the same problem in different ways, depending on how it is presented.

During this talk we will go through these and other heuristics and shortcuts used by our brain, as found by behavioral economists in almost 50 years of research, and examine them in the context of software engineering, discussing their consequences on the quality of our work.

Transcript

1. by Mario Fusco Behavioral Software Engineering
2. Two economists are walking down the street. One of them says: “Look, there’s a twenty-dollar bill on the sidewalk!” The other economist says: “No there’s not. If there was, someone would have picked it up already.”
3. The Efficient Market Hypothesis Share prices reflect all available information. It is impossible to "beat the market" consistently.
4. The Efficient Market Hypothesis Share prices reflect all available information. It is impossible to "beat the market" consistently. Money is fungible Investors are unbiased Markets are rational Eugene Fama
5. Behavioral Economics Cognitive Biases affect our decision-making Amos Tversky Daniel Kahneman
6. Econ vs. Human
7. A world of biases A bias is a thinking pattern that leads to systematic mistakes of judgment
9. Patternicity
10. Patternicity Finding meaningful patterns in meaningless noise Apophenia: the tendency to perceive meaningful connections between unrelated things or random data where no such connections actually exist
11. Patternicity Attempting to make predictions, or seek answers, based on unrelated events
12. Patternicity
13. Patternicity in software engineering • Attributing Bugs to Coincidental Code Changes Assuming that a change, even in an unrelated code caused a problem or fixed it • False Performance Correlations Assuming that a certain coding style or language construct improves or penalizes performance based on superficial observation
14. Placebo effect: simply believing that something will have a certain effect on you causes it to have that effect Patternicity in software engineering • Attributing Bugs to Coincidental Code Changes Assuming that a change, even in an unrelated code caused a problem or fixed it • False Performance Correlations Assuming that a certain coding style or language construct improves or penalizes performance based on superficial observation
15. Patternicity in benchmarking and data analysis • Overfitting Benchmark Data and Metrics ◦ Interpreting a random gain like a drop in latency as a general system improvement without real causality ◦ Tweaking a system until it scores better on a specific benchmark suite (aka benchmarkETing) ◦ Running a benchmark on a small, isolated piece of code and assuming the results scale up to the entire system ◦ Assuming synthetic benchmarks reflect production environments and workloads • Interpreting Noise as Signal ◦ Assuming that a 3% gain after a change is meaningful on benchmark results that normally fluctuate by ±5%
16. Data analysis is hard
17. Goodhart’s Law (also overfitting) & The Cobra Effect
18. Perverse incentives
19. Preventing patternicity • Measure, Measure, Measure • Practice skeptical thinking • Avoid cargo culting • Never forget that correlation is not causation • Encourage peer reviews • Be mindful of confirmation bias (e.g. always test also negative use cases) • Bonus: create a culture that embraces “I don’t know”
20. Anchoring Effect
21. The Anchoring Effect How it works: 1. Encounter an anchor (a number, value, or piece of information) 2. Use it as a reference point 3. Adjust their final decision insufficiently away from that anchor
22. If there is a number somebody will use it The Anchoring Effect In a classic experiment by Tversky & Kahneman (1974), participants spun a wheel that randomly stopped on a number between 0 and 100, then were asked to estimate the percentage of African countries in the UN. The results skewed toward the randomly spun number—demonstrating how even irrelevant anchors can bias decisions.
23. The Anchoring Effect in software engineering • Bug severity and Code quality assessments (priming effect) ◦ A bug labeled as “critical” may influence others to view it the same way, even if the real impact is minor ◦ If an early reviewer points out a specific problem in the code (e.g., “this function seems inefficient”), subsequent reviewers might focus disproportionately on that issue and ignore others ◦ Anchoring and sticking for too long with architectural or design decisions taken early in a project, under assumptions that may be no longer valid • Benchmarking and Performance Tuning ◦ Anchoring on early benchmark results and consider that “good enough,” even if deeper profiling reveals it could be much better
24. Preventing or limiting the Anchoring Effect • Make independent assessments before joining a group discussion • Delay exposure to others' opinions • Rotate roles in group activities • Ask for multiple reference points instead of just one (e.g., optimistic, pessimistic, and realistic estimates) • Set ranges, not single values • Use historical data
25. Sunk Cost Fallacy
26. Sunk cost fallacy In economics and business decision-making, a sunk cost (also known as retrospective cost) is a cost that has already been incurred and cannot be recovered
27. We are reluctant to abandon a strategy or course of action because we have invested heavily in it, even when it is clear that abandonment would be more beneficial Sunk cost fallacy
28. • Holding in losing stocks • Funding failing projects • Developing product with no customers interest • Pouring money into an underperforming ad campaign We are reluctant to abandon a strategy or course of action because we have invested heavily in it, even when it is clear that abandonment would be more beneficial Sunk cost fallacy
29. Sunk time fallacy
30. Sunk time fallacy Pleaaaaase merge my sh*t! I spent soooo much time on it that I can't stand the idea of throwing everything away
31. How to avoid the sunk cost fallacy? • Fail as fast as possible • Use prototypes (and then throw them away) • Look for early feedback • Practice dogfooding: if you don’t like your own food while other should eat it? • Use Test Driven Development • Don’t be attached to your own code • Be objective and open to constructive critique
32. Temporal Discounting
33. Temporal Discounting The decrease of the subjective value of a reward as the delay to obtain that reward increases
34. • People don’t save enough for retirements … • … or pay crazy interests on credit card debts • Companies favor projects with quick paybacks over those with higher long-term returns … • … and underinvest in R&D because the benefits are uncertain and distant while the costs are immediate and certain Temporal Discounting The decrease of the subjective value of a reward as the delay to obtain that reward increases
35. The biggest cause of technical debt and ultimately the reason why all software rots Temporal Discounting in Software Engineering is the reason why we • Skip refactoring • Defer automated tests • Choose quick-and-dirty architecture • Neglect documentation • Defer security hardening • Delay migration and tools update
36. Temporal Discounting in Software Engineering “Ship now, fix later” doesn’t take into account that “later” usually costs exponentially more in time and money
37. Mitigating Temporal Discounting (and tech debt) • Make future costs visible now • Track code quality metrics (complexity, coverage, outdated dependencies) • Quantify the cost of an outage caused by technical debt • After a delayed bug fix, quantify how much cheaper it would have been if fixed earlier • Reserve a fixed portion of team’s time for improvements, tests, or architecture rework • Use shorter feedback loops
38. Habits
39. Habits driven decision process • Status Quo Bias Sticking with the familiar option instead of re-evaluating • Default Effect Choosing whatever is pre-selected or easiest to maintain • Inertia Bias A reluctance to alter ongoing behavior patterns
40. • Sticking with the same providers • Buying the same brands • Using outdated tools • Persisting with obsolete workflows • Continuing legacy product lines Procrastination Habits driven decision process • Status Quo Bias Sticking with the familiar option instead of re-evaluating • Default Effect Choosing whatever is pre-selected or easiest to maintain • Inertia Bias A reluctance to alter ongoing behavior patterns
41. Semmelweis effect The tendency to reject new evidence or new knowledge because it contradicts established norms
42. Habits driven decisions in Software Engineering Familiarity in use of an outdated framework outweighs the pros of learning something new Copy-pasting code snippets from older projects without rethinking architecture and review purposes Continuing with homegrown tools instead of switching to a maintained industry-standard solution Maintaining outdated dependencies for years
43. Habits driven decisions in Software Engineering Still using Java 8 in production??? Familiarity in use of an outdated framework outweighs the pros of learning something new Copy-pasting code snippets from older projects without rethinking architecture and review purposes Continuing with homegrown tools instead of switching to a maintained industry-standard solution Maintaining outdated dependencies for years
44. Making habits to work in your favor • Force deliberate re-evaluation • Allocate time for learning regularly • Encourage exploration and experiments • Make the cost of outdated tools visible • Turn incidents into habit-breaking situations • Reward adaptability, not just delivery speed • Rotate roles and responsibilities • Document decisions and revisit them
45. Framing Effect
46. Framing effect: people react to a particular choice in different ways depending on how it is presented
47. Loss Aversion
48. Framing Effect and Loss Aversion in Economics Gain frame people tend to be risk-averse when choices are presented in terms of potential gains Loss frame people tend to be risk-seeking when the same choice is framed in terms of losses Promotional sell framed as “save $20” “avoid losing $20” Mutual fund described as “has gained value 70% of the time” “has lost value 30% of the time” Travel insurance promoted as “avoid a $1000 loss” “pay $30 for peace of mind” Service sold at the cost of “only $1 a day” “$365 per year” Supplier presenting an offer as “you gain a 10% discount” “you avoid a 10% surcharge”
49. Gain frame people tend to be risk-averse when choices are presented in terms of potential gains Loss frame people tend to be risk-seeking when the same choice is framed in terms of losses Bugs tracking & prioritization “Fixing this bug will improve system stability by 10%” “Not fixing this bug risks 1 in 10 users experiencing a crash” Technical debt “Refactoring now could improve performance and maintainability” “Not refactoring harms maintainability and delays future releases” Tests coverage “We improved test coverage by 15%” “We still lack coverage for 25% of critical paths” Security “Encrypting data improves compliance and security” “Not encrypting data risks fines and breaches” Framing Effect and Loss Aversion in Software Engineering
50. Reframing and changing perspective • Frame decisions both in terms of gains and losses in order to weight pros & cons correctly • Standardize decision process documenting both benefits and risks with numbers, not just narrative • Assign someone to play devil’s advocate role and deliberately reframe the problem differently • Frame incidents as learning opportunities to avoid fear-driven framing
51. Conclusions
52. Our brain is inevitably influenced by a world of biases It is not our fault: those biases made sense to preserve our species at its origin … … but now they mostly play against us
53. Listen to listen… …not to take a pause and think what you will say next Teamworking and leveraging the different skills of our mates is the strongest weapon against all these biases
54. Measure Measure Measure
55. Never stop learning Enlarge your professional toolbox
56. = I said professional
57. = I said professional and btw don’t listen to me I’m biased too!!!
58. Thank you
59. Bonus – The Keynesian Beauty Contest A beauty contest in which judges are rewarded for selecting the most popular faces among all judges, rather than those they may personally find the most attractive
60. Investors don’t buy assets they personally believe are most valuable, but what they think others will find attractive, or even what they think others will think others will find attractive Bonus – The Keynesian Beauty Contest A beauty contest in which judges are rewarded for selecting the most popular faces among all judges, rather than those they may personally find the most attractive
61. This leads to self-reinforcing cycles of sentiment, speculation, and bubbles Investors don’t buy assets they personally believe are most valuable, but what they think others will find attractive, or even what they think others will think others will find attractive Bonus – The Keynesian Beauty Contest A beauty contest in which judges are rewarded for selecting the most popular faces among all judges, rather than those they may personally find the most attractive
62. Keynesian Beauty Contest in Software Engineering • Technology, Languages & Framework Adoption Choosing Python for AI because others think most people use it • Hiring & Skills Learning something not for its actual usefulness, but following the belief that other companies will require it • Hype Cycles & Fads in Tech Using a blockchain when a normal DB could perfectly do the job (which happens in 100% of cases) Network effects and community expectations matter more than pure technical merit
63. Agentic AI won hands down the Keynesian Beauty Contest 2025 Is it here to stay? What will be the next winner?