Cognitive in Software Engineering: A Systematic Mapping and Quasi-Literature Review Rahul Mohanani, Iflaah Salman, Burak Turhan, Pilar Rodriguez, Paul Ralph

Abstract—One source of software project challenges and failures is the systematic errors introduced by human cognitive biases. Although extensively explored in cognitive , investigations concerning cognitive biases have only recently gained popularity in software engineering (SE) research. This paper therefore systematically maps, aggregates and synthesizes the literature on cognitive biases in software engineering to generate a comprehensive body of knowledge, understand state of the art research and provide guidelines for future research and practise. Focusing on antecedents, effects and mitigation techniques, we identified 67 articles, which investigated 47 cognitive biases, published between 1990 and 2016. Despite strong and increasing interest, the results reveal a scarcity of research on mitigation techniques and poor theoretical foundations in understanding and interpreting cognitive biases. Although bias-related research has generated many new insights in the software engineering community, specific bias mitigation techniques are still needed for software professionals to overcome the deleterious effects of cognitive biases on their work.

Index Terms—Antecedents of , cognitive bias, , effects of cognitive bias, quasi-systematic literature review, systematic mapping, systematic literature review —————————— u ——————————

1 INTRODUCTION OST research on software engineering (SE) practices • Memory, e.g., remembering previous projects as M and methods focuses on better ways of developing having gone better than they did. software. That is, most studies present an ostensibly good • Perception, e.g., perceiving a unit test as designed way of doing something (e.g., a design pattern). Another to break the system when it is actually designed to way to improve software development is to identify com- confirm that the system works. mon errors (e.g., antipatterns), their causes and how to Cognitive biases help to explain many common soft- avoid them. This is where the concept of cognitive biases is ware engineering problems in diverse activities including exceptionally useful. design [3], [4], [5], testing [6], [7], requirements engineering A cognitive bias is a common, systematic error in human [8], [9] and software project management [10]. reasoning [1]. For example, is the ten- While there is no definitive index, over 200 cognitive bi- dency to pay undue attention to sources that confirm our ases have been identified, and few studies attempt to clas- existing beliefs while ignoring sources that challenge our sify cognitive biases [11]. Some research in the information beliefs [2]. Within software development context, cognitive systems community (e.g. [2], [12], [13]) notwithstanding, biases may affect: no previous comprehensive literature review of research on • Behavior, e.g., deciding to use a relational data- cognitive biases in SE exists. This hinders development of an base because it seems like a default option. actionable, cumulative body of knowledge. This literature • Belief, e.g., strongly believing that well-docu- review tries to systematically uncover all the cognitive bi- mented requirements are crucial for success with- ases investigated in SE research, not limited to any specific out any good supporting evidence. knowledge area of SE by explicitly focusing on the anteced- • Estimation, e.g., (over/under)-estimating the time ents and effects of biases, and any debiasing techniques used and effort needed to develop a system. to mitigate the effects of cognitive biases. The aim of this study is therefore to document the state of the art of human ———————————————— cognitive bias related research in SE, addressing the follow- • R. Mohanani, I. Salman, P. Rodriguez are with M3S Group, University of Oulu, Oulu, Finland. ing research question. E-mail: [email protected], [email protected], pilar.rodri- Research question: What is the current state of research on [email protected] cognitive biases in software engineering? • B. Turhan is with the Department of Computer Science, Brunel University London, London, UK. To address this question, we adopt a quasi-systematic E-mail: [email protected] literature review and systematic mapping approach. This • P. Ralph is with the Department of Computer Science, University of Auck- combination facilitates classifying and aggregating find- land, Auckland, New Zealand. ings into a comprehensive and structured body of E-mail: [email protected] knowledge. By presenting gaps in available research and discussing implications to research and practise, this study

provides grounded avenues for future bias-informed in- 4. Psychological phenomena, for example, the Polly- vestigations with a view to establishing foundational in- anna Principle - an individual's “tendency to be sights in application of in SE. overly positive in perception, memory and judg- This paper is organized as follows: the next section pro- ment” may reinforce [12]. vides a brief primer on cognitive biases, focusing on their 5. Human cognitive limitations, for example, diffi- causes, effects and consequences. Section 3 describes our culty in quickly processing complex information research approach. We then present the findings of our sys- [P24]. tematic mapping (Section 4) and literature review (Section 6. Motivational factors such as rewards and incen- 5). Section 6 discusses the implications and limitations of tives, responsibility / empowerment, and stress, our findingsand offers avenues for future research. Section risk or lack of communication channels [22]. 7 summarizes the study’s contributions. 7. Adaptation to natural environments [33]. While the causes of cognitive biases are of great interest in psychology, SE researchers focus more on their effects 2 COGNITIVE BIASES: A BRIEF PRIMER [21]. While Section 5.2 provides a more comprehensive list, Human behavior and cognition constitutes a critical re- some examples include: search area in software engineering (SE) [14], [15], [16], • Confirmation bias (defined earlier) is implicated in [17]. Although agile methodologies and empirical research the common antipattern where unit tests attempt highlight the importance of people and teams involved in to confirm that the code works rather than to software development, SE research and practice continue break it [34]. to focus more on technologies, techniques and processes • Optimism bias, the tendency to produce unrealisti- than common patterns of human-related errors and their cally optimistic estimates [35], contributes to the manifestation in project failures. tendency for all kinds of projects (not only soft- Moreover, many studies on human decision-making in ware projects) to exceed their schedules and budg- software engineering adopt theories and concepts from ets [36]. psychology to address issues in, for example, decision sup- • The framing effect can lower design performance. port systems [2], [18], software project management [19] The framing effect refers to the tendency to give and software engineering and development paradigms different responses to problems that have surface [20], [12], [21]. Numerous systematic literature reviews dissimilarities but are formally identical [37]. have explored psychological and sociological aspects of SE Framing desiderata more formally and defini- including motivation [22], personality [23], organizational tively reduces design quality by impeding creativ- culture [24] and behavioral software engineering [25]. ity [3], [38]. These studies collectively demonstrate the importance of SE researchers are also interested inhibiting cognitive human cognition and behavior for software engineering biases or mitigating their deleterious effects [21], that is, de- success. biasing [39], [40]. As Fischoff [39], explains, debiasing inter- Since Tversky and Kahneman [26] introduced the term ventions can be divided into four levels: in the early 1970s, a vast body of research has investigated To eliminate an unwanted behavior, one might use an escalation de- cognitive biases in diverse disciplines including psychol- sign, with steps reflecting increasing pessimism about the ease of per- ogy [27], medicine [28] and management [13]. Kahneman fecting human performance: (A) warning about the possibility of bias [29] went on to differentiate fast, “system one” thinking without specifying its nature… (B) describing the direction (and per- from slow, “system two” thinking. System one thinking is haps extent) of the bias that is typically observed; (C) providing a dose unconscious, effortless, intuitive, and leads to systematic of feedback, personalizing the implications of the warning; (D) offer- errors (i.e. biases). System two thinking, contrastingly, is ing an extended program of training with feedback, coaching, and conscious, effortful, more insightful, more rational, more whatever else it takes to afford the respondent cognitive mastery of statistical and less prone to systematic errors [29]. the task. (p. 426) However, system-one thinking is not the only source of biased reasoning. More generally, cognitive biases can be The problem with this approach is that options A, B and caused by: C are ineffective [41], [42], and option D can be very expen- 1. Heuristics, that is, simple and efficient, but not nec- sive. Fischoff therefore offered a fifth option: redesign the essarily most accurate, rules for making decisions person-task system to inhibit the bias. Planning Poker, the and other judgments [29]. effort estimation technique used in many agile methods, 2. Illusions [30]—both perceptual and social—for ex- illustrates option five—it redesigns the person-task system ample, the [31]. to prevent developers from anchoring on each others’ ef- 3. Group processes including groupthink - a psycho- fort estimates [43]. logical phenomenon that occurs within a group of people in which the desire for harmony or conform- 3 RESEARCH METHODOLOGY ity in the group results in an irrational or dysfunc- tional decision-making outcome - by inhibiting crit- This study combines systematic mapping with a quasi-sys- ical thinking to avoid conflicts that may lead to ex- tematic literature review. A systematic mapping study cessive optimism [32]. (SMS) is a method that is conducted to get an overview of a particular research area. A systematic map provides a

structure of the type of research reports rather than extract- SQ3. What debiasing approaches are investigated in SE? ing specific details by categorizing the available details on a broad or poorly explored topic [44], [45]. 3.3 Systematic mapping / review protocol Meanwhile, a systematic literature review (SLR) aggre- To improve rigor and reproducibility of our review pro- gates and evaluates an area of literature vis-à-vis specific cess, we developed and mutually agreed upon an initial research questions [46]. A quasi-SLR uses the same meth- review protocol [53]. The review protocol was improved by odology with less extensive meta-analysis [47]; i.e., statis- iterative assessment and periodic review. We summarize tically combining quantitative results from different stud- the major stages of our review protocol as follows. ies of the same context. We employ a quasi-SLR because 1. Execute the search string “software AND cognitive there are insufficient empirical studies with overlapping bias” for all years up to and including 2016 in online variables to facilitate statistically sound meta-analysis. databases (see Section 3.4.1). Combining an SLR and SMS is common—the SLR syn- 2. Remove any duplicate entries using automated and thesizes the qualitative findings while the SMS provides then manual de-duplication (see Section 3.4.2). bibliometric analysis and appropriate categorization of 3. Apply the inclusion and exclusion criteria de- primary studies based on a priori elements [48], [49], [50], scribed in Section 3.5.1. [51]. Wherever possible, we followed the guidelines pro- 4. Expand the sample through retrospective snowball- vided by Kitchenham and Charters [46] and Petersen et al. ing on reference lists to find additional studies; re- [45]. peat steps 2 and 3 for additional studies identified in this stage. 3.1 Objectives 5. Expand the sample by reviewing the publication Following Goal-Question-Metric [52], the objective of this lists of the most active authors for additional stud- paper is as follows. ies; repeat steps 2-4. 6. Assess the quality of the selected primary studies Purpose: To analyze SE literature concerning cognitive biases for the based on a priori guidelines (see Section 3.5). purpose of identifying, aggregating, categorizing and synthesizing 7. Extract the required data from the primary studies the evidence available in the primary studies, with respect to investi- based on the research questions. gating the antecedents to cognitive biases, effects of cognitive biases The remainder of this section provides further details on and debiasing techniques; from the point of view of researchers in the each of these steps. context of empirical and non-empirical studies conducted in academic and industrial contexts. 3.4 Literature search 3.2 Research questions 3.4.1 Database selection and search string formation For clarity, we distinguish between mapping study re- We searched five online databases recommended by Kitch- search questions (MQs) and systematic review research enham and Charters [46]: IEEE Xplore, Scopus, Web of Sci- questions (SQs). The research questions are defined using ence, the ACM Digital Library and Science Direct. These the population, intervention, comparison and context cri- databases are frequently used to conduct SLRs on com- teria, as proposed by Kitchenham and Charters [46]. The puter science and SE related topics; and in our experience, research questions for the mapping study are as follows: provide good coverage, filtering and exportability func- tions of the searched literature. MQ1. What cognitive biases are investigated in SE stud- We defined the search string as “software AND cognitive ies? bias”. Where available, we used filters to avoid articles MQ2. How are the publication trends concerning cogni- from domains other than SE. As a result, we reached an in- tive biases in SE? itial sample of 826 studies. Table 1 summarizes the search results per online database. MQ3. Which SE researchers are most active in investigat- ing cognitive biases? 3.4.2 Citation management and de-duplication We used RefWorks (www.refworks.com), to store and MQ4. Which SE knowledge areas are most often ad- organize the retrieved articles, and to automatically re- dressed by research on cognitive biases? move duplicate articles. We then exported the biblio- MQ5. In which SE outlets is most cognitive bias research graphic entries to a spreadsheet, where we tagged each en- published? try with a unique three-digit identification number. We manually reviewed the articles for additional duplicates. MQ6. Which research methodologies are most frequently This produced a sample of 518 articles. used to investigate cognitive biases in SE? Meanwhile, the research questions for the systematic re- 3.5 Primary study selection view are: 3.5.1 Primary study screening process SQ1. What antecedents of cognitive biases are investi- The purpose of screening is to remove articles that do not gated in SE? provide direct evidence concerning the study’s objectives. SQ2. What effects of cognitive biases are investigated in SE?

Inclusion and exclusion criteria were developed, then re- Due to the large number of articles (518), we screened viewed and agreed by the whole team. This resulted in them first based on their titles, consulting the abstract or three inclusion criteria and four exclusion criteria. entire article only when necessary to reach a confident Articles were included if: judgment. 1. The context of the study is software engineering, To develop a common understanding of the topic of where we define software engineering as “a sys- study and inclusion / exclusion criteria, two of us piloted tematic approach to the analysis, design, assess- the screening process on 20 randomly selected papers. This ment, implementation, test, maintenance and reen- produced medium to high agreement (Cohen’s Kappa = gineering of software, that is, the application of en- 0.77 [55]). We then refined the protocol, and screened an- gineering to software” [54]. other 20 randomly selected papers which yielded a higher 2. The article explicitly involves at least one cognitive agreement (Cohen’s Kappa = 0.9). Then, we completed the bias. remainder of the screening. This produced 42 primary 3. The article is published in a journal or in a confer- studies. ence, workshop or symposium proceedings. [55] Articles were excluded if: 3.5.2 Retrospective snowballing 1. The article was not peer reviewed or was in a lan- Next, we expanded the sample through retrospective guage other than English. snowballing. That is, we checked the references of all in- 2. The article is a doctoral / master’s dissertation or cluded studies (subject to the inclusion and exclusion cri- research plan, short paper or report thereof. teria) for additional relevant studies. Each time we found 3. The article is a secondary or tertiary study. a new study, we also checked its references, leading to four 4. The article’s references to cognitive biases were tan- iterations (Table 2). This resulted in including 16 additional gential to its purpose or contributions. primary studies.

TABLE 1 DATABASE SEARCH RESULTS

Database Search string Date Filters applied Results IEEE (software AND 20th December Only ‘conference publications’ and ‘journal & 153 Xplore “cognitive 2016 magazines’ were included. bias”) ACM “software” 20th December ‘Newsletters’ category was excluded. 69 Digital AND “cogni- 2016 Library tive bias” Scopus software AND 20th December Only ‘computer science’ category was included. 296 “cognitive 2016 bias” Web Of software AND 20th December No filters were relevant. 15 Science “cognitive 2016 bias” Science software AND December Only ‘journals’ and ‘computer science’ category 293 Direct “cognitive 2016 were included. bias” Total 826

TABLE 2 3.7 Data extraction RETROSPECTIVE SNOWBALLING Next, we compiled a list of data elements to extract from the primary studies. Data extraction form is conceptual- Snowballing round # Articles included ized to answer the research questions and Table 5 provides Round 1 10 summarization of the specific data elements extracted from Round 2 4 each primary study. We extracted the data using NVIVO (www.qsrinternational.com), which facilitates organizing Round 3 1 and analyzing unstructured qualitative data. We recorded Round 4 1 only explicit information as presented in the primary studies to Total 16 avoid interpretation bias, and recorded a particular cogni- tive bias if and only if it formed the core topic of investiga- tion or discussion in a paper. Some articles discussed more than one cognitive bias. 3.5.3 Authors’ analysis Next, we reviewed the publication records of the most pro- lific authors. For every author of four or more primary 4 SYSTEMATIC MAPPING RESULTS studies (this covered 95% of the study pool), we reviewed This section addresses each mapping question (MQ). We their Google Scholar profile (scholar.google.com) or, if not refer to primary studies with a ‘P’ (e.g. [P42]) to distinguish available, their personal website. This identified 9 addi- them from citations to other references (e.g. [42]). tional primary studies. Retrospective snowballing on these new articles did not produce any additional primary stud- 4.1 Cognitive biases investigated in SE ies. This brought the total to 67 primary studies (see Ap- Regarding MQ1 (What cognitive biases are investigated in SE pendix B for a complete list of primary studies). studies?), the primary studies investigated 47 different cog- nitive biases (Fig.1). Each bias is defined in Appendix A. 3.6 Quality assessment The most investigated cognitive biases are anchoring bias To assess the quality of the primary studies, we synthe- (27), confirmation bias (25), and availability bias (17). sized multiple recommendations ([56], [57], [58]) into a sin- Some articles use different names for the same bias (e.g. gle set of yes or no quality assessment criteria, to eliminate “optimism bias”, “over-optimism bias”). We combined subjectivity to the best extent. We then divided the primary only obviously synonymous biases as indicated in Appen- studies into two mutual exclusive groups—empirical (48) dix A. We return to the issue of synonymous biases, which and non-empirical (19)—since some criteria only apply to is more complex than it first appears, in Section 6.2. empirical studies (Tables 3 and Table 4). To improve rigor and reliability, we ran a pilot where 4.2 Number of studies two authors independently assessed the quality of 10 ran- Fig.2 addresses MQ2 (How are the publication trends concern- domly selected primary studies, discussed disagreements, ing cognitive biases in SE?). The earliest paper published refined mutual understanding of the categories, and re- was in 1990. There were one or two papers per year until vised the quality assessment instrument. Then, each as- 2001, after which we see a noticeable but inconsistent in- sessed half of the remaining studies. crease in publications, peaking in 2010. The apparent rea- We used the quality scores, based on the quality assess- son for the spike seen in 2010 could be attributed to an ac- ment criteria checklist, to better identify the relevance of all tive contribution (4 publications) co-authored by G. Calikli included articles and also to help us extract data for subse- and A. Bener, who even feature in the list of most active quent mapping and review in a better and more objective authors (see Section 4.3). 2016 records only 2 publications. manner. In this study, we do not reject any article based on This might be because the digital libraries did not index all the quality assessment rubric, as each primary study satis- the relevant publications at the time of the search. fies at least 50% of the quality criteria. The mean quality score (percentage of quality criteria satisfied against over- 4.3 Most active authors all quality criteria checklist) for empirical studies is 83.74% To investigate MQ3 (Which SE researchers are most active in with a maximum value of 92% and minimum of 67%. investigating cognitive biases?), we ranked all 109 authors by Whereas, the mean quality score for non-empirical studies number of publications in our sample. Of these, 97 au- is 84.90% with a maximum value of 100% and a minimum thored just one or two publications. The top four authors of 50%. Moreover, for this study we conceptualized quality published five or more publications (Table 6), while the rest assessment process as an assessment of the reporting prac- of the authors had at the most 3 publications each, and tices of an included article, rather than judging the actual hence they are not featured in Table 6. Magne Jorgensen is quality of the research involved. clearly the most prolific author in this area. Some of the ac- tive authors are frequent collaborators; for instance, Calikli and Bener co-authored eight publications, while Jorgensen and Molokken collaborated on four.

TABLE 3 CLASSIFICATION OF PRIMARY STUDY BASED ON RESEARCH TYPE

Research Type Description Primary studies Empirical Empirical research studies can be defined as re- P1, P2, P5, P6, P7, P9, P10, P11, P12, P13, P14, search based on observation (viz. interviews, case P16, P17, P18, P19, P20, P25, P26, P27, P30, studies), to test a hypothesis (viz. experimenta- P31, P33, P36, P43, P57, P59, P60, P61, P58, tion) or to construct a hypothesis (viz. grounded P63, P64, P40, P41, P42, P52, P53, P54, P55, theory). P50, P51, P56, P46, P48, P49, P44, P45, P65, P67. Non Empirical Non-empirical research covers studies that are P3, P4, P8, P15, P21, P22, P23, P24, P32, P35, conducted without any empirical methodology P39, P62, P47, P28, P29, P34, P37, P38, P66. (viz. theoretical, conceptual or opinion papers).

TABLE 4 QUALITY ASSESSMENT CHECKLIST

Quality criteria Empirical Non-empirical

Whether a motivation for the study was provided? X X Whether the aim (objectives, research goal, focus) were reported? X X Whether there was a mentioning of the context (SE knowledge areas) in X X which the study was carried out? Whether the research design or methodology to address the aims of the re- X search was provided? Whether a description of used samples was provided? X Does the paper position itself in the current body of existing literature? X X Whether the data collection method(s) was reported? X Whether The data analysis method(s) was reported? X Whether the threats to validity were reported? X Whether there was any relevance (industry OR academia) reported? X X Whether the relationship between researchers and participants were men- X tioned? Whether the findings / conclusion been reported or not? X X

TABLE 5 DATA EXTRACTION ELEMENTS

Element RQ Description Year MQ2 The publication year of the study. Source avenue MQ5 The name of the journal / conference or workshop where the study was published. Publication type MQ5 We defined two categories for this - conference and journal. Further, we classified workshop and symposium publications as a conference proceeding. Author name MQ3 The authors of the study. Subfield of SE MQ4 The classification was done based on SWEBOK version 3 knowledge areas of SE. Research MQ6 Experiment, grounded theory, survey, case study, interview, think-aloud protocol anal- methodology ysis. Cognitive bias MQ1 The targeted bias(s) as the focus of investigation or discussion in the study. Antecedents SQ1 The factors explored as an antecedents to the investigated cognitive bias(s). Effect of bias SQ2 The reported effects of the investigated cognitive bias(s). Debiasing ap- SQ3 Debiasing treatment / technique / strategy reported to mitigate the effects of investi- proaches gated cognitive bias(s).

TABLE 6

MOST ACTIVE AUTHORS 5 SYSTEMATIC REVIEW RESULTS

Name of the author # Primary studies This section reports the findings of the quasi-SLR. Follow- ing the three SLR research questions, it is divided into an- Jorgensen 14 tecedents of biases, consequences of biases, and debiasing Bener 8 strategies. Calikli 8 Molokken 5 5.1 Antecedents of cognitive biases This section addresses SQ1 by reports the antecedents of 4.4 SE Knowledge areas investigated for cognitive cognitive biases investigated in the primary studies. Table biases 10 provides a summary of findings reported in this section. To answer MQ4 (Which SE knowledge areas are most often ad- 5.1.1 Anchoring and adjustment bias dressed by research on cognitive biases?), we categorized the primary studies using the knowledge areas specified in the Anchoring and adjustment is a common heuristic in which Software Engineering Body Of Knowledge [59], as shown one makes estimations by adjusting an initial value called in Table 7. The most frequently investigated knowledge an anchor. Anchoring bias is “the tendency, in forming per- area is SE management (22) followed by software construc- ceptions or making quantitative judgments of some entity tion (13). Many critical knowledge areas including require- under conditions of uncertainty, to give excessive weight ments, design, testing and quality are under-represented. to the initial starting value (or anchor), based on the first Table 7 does not include mathematical foundations, com- received information or one’s initial judgment, and not to puting foundations, engineering foundations, SE econom- modify this anchor sufficiently in light of later infor- ics, software configuration management or SE profession- mation” [60, p. 51]. In other words, anchoring bias is the alism because no studies corresponded to these areas. tendency to stick too closely to the anchor [26]. Suppose, for example, that two developers are discuss- 4.5 Preferred publication outlets ing how long a task will take. The first developer guesses We summarize the findings concerning MQ5 (In which SE two days. Further suppose that, if not for the initial esti- outlets is most cognitive bias research published?) in Table 8. mate (anchor), the second developer would have guessed Articles are scattered across many outlets, with 58% in one week. However, she estimates three days by adjusting journals or academic magazines, and the rest in confer- the anchor. ences, workshops or symposiums. The outlet with the Several primary studies suggest potential antecedents most articles (5) is Journal of Systems and Software. of anchoring bias, including (lack of) expertise. According to Jain et al. experts are less susceptible to anchor bias than TABLE 7 novices [P17]. Meanwhile, uncertainty, lack of business SE KNOWLEDGE AREAS INVESTIGATED knowledge and inflexible clients exacerbate anchoring during decision-making in project-based organizations SE knowledge area # Primary studies [P65]. Other biases, including confirmation bias and avail- SE Management 22 ability bias, may also promote anchoring and adjustment Software Construction 13 [P18]. Software Design 11 Meanwhile, one primary study found that system de- Software Requirements 7 signers anchor on preconceived ideas, reducing their ex- Software Testing 6 ploration of problems and solutions [P35]. Similarly, devel- SE (General) 4 opers tend to re-use existing queries rather than writing Software Quality 1 new ones, even when the existing queries do not work in Software Maintenance 1 the new situation [P2]. Two primary studies ([P18], [P19]) SE Process 1 investigated developers in adjusting systems due to SE Models & Methods 1 change requests. They found that missing, weak, and ne- glect of traceability knowledge leads developers to anchor on their own understanding of the system, which causes 4.6 Frequently utilized research methodology poor adjustments (deficient modifications). Another study Table 9 addresses MQ6 (Which research methodologies are [P21] found that decision-makers struggle to adjust to the most frequently used to investigate cognitive biases in SE?). new or changed environments because they were an- Most of the empirical studies employed laboratory experi- chored on their outdated understanding of a previous con- ments. Correspondingly, predominately qualitative re- text. search approaches (e.g. case studies) are underrepresented. The astute reader may have noticed something amiss Nine empirical papers reported multiple studies, of which here. Anchoring bias refers to insufficiently adjusting a nu- seven reported multiple experiments whereas, two utilized merical anchor to estimate a numerical property. “Anchor- multimethodological approach. ing” on pre-conceived ideas or outdated knowledge and Other approaches includes studies that used pre-existing “adjusting” queries and code is not anchoring and adjust- data sets or did not report sufficient details about the re- ment as understood in the cognitive biases literature. We search methodology employed.

TABLE 8 TOP PUBLICATION OUTLETS

Source Avenue # Primary studies Journal of Systems and Software 5 Journal of Software 3 Systems Engineering Conference 3 International Conference on Software Engineering 3 Information and Software Technology Journal 2 Empirical Software Engineering Journal 2 International Conference on Evaluation and Assessment in Software Engineering 2 IEEE Transactions on Software Engineering 2 Communications of the ACM 2 Information & Management Journal 2 Information Systems Journal 2 International Conference on Information Systems 2 International Conference on Predictive Models in Software Engineering 2 International Symposium on Empirical Software Engineering and Measurement 2 Psychology of Programming Interest Group Workshop 2 Advanced information systems engineering Journal 1 International Journal of Project Management 1 European Conference on Cognitive Science 1 AI Magazine 1 Americas Conference on Information Systems 1 Canadian Conference on Electrical and Computer Engineering 1 Document Engineering (Symposium) 1 Ethics and Information Technology Journal 1 European Conference on Information Systems 1 European Software Process Improvement 1 IASTED International Conference on Software Engineering 1 Industrial Management & Data Systems Journal 1 Information Systems Management Journal 1 Information Systems Research Journal 1 International Conference on Electronics, Communications and Computers 1 International Conference on Information Science and Technology 1 International Conference on Information, Business and Education Technology 1 International Conference on Intelligent user interfaces 1 International Workshop on Emerging Trends in Software Metrics 1 Journal of Association for Information Systems 1 Journal of Visual Languages & Computing 1 Management Science Journal 1 Proceedings of AGILE conference 1 Research in Systems Analysis and Design: Models and Methods Journal 1 Scandinavian Journal of Information Systems 1 Science of Computer Programming Journal 1 Software Quality Journal 1 Transaction on Professional Communication Journal 1 Ubiquity Journal 1 Workshop on a General Theory of Software Engineering (GTSE) 1 International Workshop on Cooperative and Human Aspects of Software Engineer- 1 ing

will revisit this confusion in Section 6.2. For now, we or- als may use inappropriate keywords because they are fa- ganize results according to what primary studies ostensibly miliar and easy to remember, or they may struggle to find investigate answers in unfamiliar locations in the documentation. Nevertheless, prior-knowledge has positive overall effects TABLE 9 on efficiency and effectiveness in documentation searches FREQUENTLY UTILIZED RESEARCH METHODOLOGY [P14]. Availability bias can also manifest in project-based or- Research methodology # Primary studies ganizations, when decisions related to future estimates Experiment 26 concerning project time, costs and other resources are Case study 6 made solely based on information concerning events that Interview 3 are either easy to recall, or due to lack of any available his- Grounded theory 3 torical records or absence of lesson learnt from previously Protocol analysis 3 completed projects [P65]. Survey 3 5.1.4 Confirmation bias Other approaches 8 Confirmation bias is the tendency to pay undue attention 5.1.2 Optimism bias to sources that confirm our existing beliefs while ignoring sources that challenge our beliefs [2]. For instance, the ten- Optimism bias is the tendency to produce overly optimis- dency of software testers to choose test cases that confirms tic, estimates, judgments and predictions [61]. Most of the the available hypothesis instead of selecting test cases that primary studies addressing optimism bias involve practi- are inconsistent with the hypothesis. tioners in the context of effort estimation. Several factors One of the antecedents to confirmation bias is the pres- appear to aggravate optimism bias. ence of prior knowledge of software practitioners during Practitioners in technical roles (e.g. developers) appear knowledge retrieval from software documentation. Alt- more optimistic than those in non-technical roles (e.g., soft- hough, using prior-knowledge is time-effective, it might ware managers), at least in estimating web development result in manifestation of confirmation bias in software tasks [P52]. The implication here is surprising: knowing practitioners as the search is then mainly focused on con- more about specific tasks leads to less accurate effort esti- firming the answers that they already know from their mates. prior knowledge, i.e., practitioners tried to confirm their Meanwhile, one primary study [P54] of students en- prior knowledge [P14]. rolled in software development course had several inter- Recency of experience and training levels in logical rea- esting findings: soning and mathematical proof reading are reported to be • Estimates of larger tasks (e.g. whole projects) other antecedents to confirmation bias. For example, par- are more accurate than estimates of decom- ticipants (developers/testers) who were experienced but posed tasks (e.g. a single user story). inactive as a developer/tester showed less confirmation • Estimates for more difficult subtasks are more bias than those who were both experienced and active in optimistic while estimates for easy subtasks are their roles [P5]. However, the study does not report the rea- more pessimistic. sons for such an observation. Calikli and Bener also report • Students are also optimistic about the accuracy that participants who had training in logical reasoning and of their estimates; that is, their confidence inter- mathematical proof reading manifested less confirmation vals are far too tight. bias in software testing [P5]. This is due to the fact that they • Estimates are more accurate in hindsight; that were trained to approach the task at hand more logically is after a task is completed. rather than exercising the program in the required way Human perceptions and abilities also appear to affect only. optimism. For example, practitioners judge more concrete, near-future risks more accurately than more abstract, far- 5.1.5 Fixation future risks [P25]. Fixation is the tendency to focus disproportionately on one Contrastingly, optimism bias is related to the way some aspect of a situation, object or event—particularly self-im- projects are initiated. For example, Winner’s curse is a phe- posed or imaginary barriers [12]. Only one primary study nomenon in which the most competitive bid is selected explicitly investigated fixation [P20]. It found that present- [P61]. Rather than the most efficient or capable organiza- ing desiderata as requirements leads to more fixation on tion’s bid, the most competitive bid is often the least real- those desiderata than presenting them as a less-structured istic, or even least honest. list of ideas. 5.1.3 Availability bias 5.1.6 Overconfidence bias Availability bias is a tendency to allow information that is Overconfidence bias is the tendency to overestimate one’s easier to recall unduly influence preconceptions or judg- skills and abilities [63]. The manifestation of (over)-confi- ments [62]. dence bias is attributed to ‘planning-fallacy’- the tendency For example, availability bias manifests in two ways to underestimate project completion time [P47]. A very when searching software documentation [P14]: Profession- specific focus towards the completion of short-time tasks

might lead project managers to neglect other useful infor- problems or inter or intra team communication problems mation, leading to illusion of control and overconfidence [P65]. in their abilities [P47].The lack of one’s ability to reflect on one’s own past experiences and fundamental (primary) 5.1.12 Sunk-cost fallacy way of thinking and assessing a situation might also lead Sunk-cost fallacy is a logical error due to the tendency to to overconfidence bias among software developers [P47]. invest more future resources in a situation, in which a prior investment has been made, as compared with a similar sit- 5.1.7 Pessimism bias uation in which a prior investment has not been made [68]. Pessimism bias is the tendency to report the status of any Sunk-cost fallacy is manifested during software project de- task in worse shape than the actual situation [19]. In SE, cision making, where future decisions about the cost or pessimism bias manifests, when a project manager reports time estimates are chosen based on only immediate bene- a situation in far worse condition than it really is [P33]. One fits [P65]. In such scenarios, costs and time estimates are of the major reasons contributing towards such behavior is disregarded mainly due to inherent humane characteristics to acquire more resources (e.g., funds, developers etc.) to of being stubborn or of being in one’s confort-zone for ex- successfully complete the project. This might be stemming tended time period [P65]. from the lack of confidence in one’s abilities, or to safe- guard one’s own reputation or of the team’s, to complete 5.2 Effects of cognitive biases the project in stipulated time in the contract [P33]. This subsection addresses SQ2 by describing the effects of cognitive biases found in the primary studies. Table 11 5.1.8 summarizes these results. When people know the actual outcome of a process, they tend to regard that outcome as having been fairly predict- 5.2.1 Anchoring and adjustment bias able all along – or at least more predictable than they Anchoring and adjustment bias affects multiple aspects of would have judged before knowing the outcome [64]. In software development including development, effort esti- this regard, weak historical basis of lessons learned is an mation, implementing change requests and prototyping. antecedent to hindsight bias in context of project based or- For example, in the context of artifact and query re-use, ganizations [P65]. However, the study does not clearly es- developers who anchored on the existing solutions – using tablish any link or rationale, and lacks empirical evidence it as an initial or starting base, introduced unrequired func- concerning the manifestation of hindsight bias and its an- tionality as part of the final solution. This tendency re- tecedent. sulted in errors and previously omitted functionalities pro- pogating to the final solution [P2], [P44]. 5.1.9 Mere exposure effect Furthermore, productivity-estimates of software devel- It is a tendency to develop a preference for things that peo- opment teams were affected due to anchoring bias, as pro- ple are familiar with [65]. This bias is expressed when a ject managers anchored their effort, time and cost estimates project participant prefers to retain its current responsibil- to the initial lower estimates (conservative estimate fig- ities and role in the project as opposed to a different role. ures) in comparison with actual project status report. Such Project participants often disregard any change due to the behavior provided project managers an advantage of justi- fear of moving out of the comfort-zone or due to fear of fying their proposed time and resources for the project accepting new responsibilities [P65]. [P53]. System analysts, after clearly understanding a system, 5.1.10 Parkinson’s Law effect tend to illogically anchor to their current understanding ra- It is a tendency to procrastinate the execution of activities ther than reconsidering the system’s initial and present sit- until the agreed end date [66]. According to the only pri- uation. Similarly, it is possible that an analyst adjusts to the mary study focusing on Parkinson’s Law effect, lack of mo- initially prepared prototype rather than preparing a new tivation during tasks extending for longer than usual du- withconflicting information [P4]. ration with poor monitoring of the progress, might be the Research suggests multiple types of anchors besides reason for the manifestation of this bias especially in pro- point estimates when software developers deal with ject guided organizations [P65]. change requests, especially when traceability is missing [P19]. For example, rather than looking into the code-base 5.1.11 that implemented the functionality (related to the change), The halo effect is the tendency to use global evaluations to they focus on (anchor) those parts of implementation that make judgments about specific traits [67]. For example, in they worked on in the past and adjust the solution accord- a job interview, the interviewer might incorrectly infer that ingly [P19]. The solution may suffer incorrect changes (ad- more charismatic candidates are more technically compe- justment) because traceability was missing or weak. tent. This effect tends to occur when employees’ perfor- Besides the industrial context, effects of anchoring and ad- mances are evaluated in the software organizations. In this justment bias can also be observed among students in aca- respect, subjective evaluation criteria are an antecedent to demic context. For example, information technology stu- halo effect because first impression promotes the judge- dents anchored to the content of an earlier course while ments in making subjective evaluations. The first impres- guessing initial architectural solutions of a problem, in the sion however, might be an effect of employee’s personal software architecture class [P66].

5.2.2 Confirmation bias individuals’ experiences may not be consistent with the re- The tendency of confirming prior beliefs rather than look- cent state of the system [P14], [P18]. ing for counter evidence has affected many areas of SE. For Availability bias can lead to many problematic situa- example, this approach led practitioners to a false belief tions, some of which are as follows: about the completeness and correctness of their queries • Availability bias might cause over-representation during software documentation searching [P14], and as a of specific code because certain code-features will result, they searched only those parts of the documentation appear more frequently that are developed or that confirmed the answers to their queries. Similarly, de- maintained by specific developer or a team of de- velopers, while acquiring information to deal with a velopers, or are easily remembered by them [P34]. change-request tend to confirm their prior knowledge ra- • Developers sometimes might even end up over- ther than exploring the implementation completely [P19]. rating their individual contribution unrealistically Technical people and business people interact with due to manifestation availability bias [P34]. each other with certain notions. Each group has its own no- • Availability bias might even contribute to certain tion (confirmation bias) that the other group is not going to controversies. For instance, due to prior experi- buy their idea or understand their point [P29]. This leads ence, developers would choose languages that to constant conflicts between the two groups during joint they are comfortable with inspite of better or more work. suitable languages available to choose from [P34]. Moreover, tradeoff studies, where multiple alternatives 5.2.5 Framing Effect to a solution are considered with multiple criteria, also suf- fer from confirmation bias. The analysts and decision mak- The framing effect is the tendency to react differently to sit- ers, while analyzing the alternatives or criteria, tend to ig- uations that are fundamentally identical but presented (or nore the results that do not confirm their preconceived framed) differently. One study [P20] found that the fram- ideas [P39]. In one of the opinion studies, it is suggested ing desiderata as requirements reduced creativity in soft- that software practitioners such as testers and require- ware designs (compared to framing as “ideas”). ments analysts might fall prey to confirmation bias and de- 5.2.6 sire the results they believe in during pilot-runs before the Attentional bias refers to how our recurring thoughts can actual task, thus risking the entire project [P28]. bias our perceptions [70]. For example, suppose a project Confirmation bias in software testing context leads to manager is conducting a performance review with a soft- an increased number of production defects. A high level of ware developer. A developer with an anxiety disorder defect rate is therefore may be directly related to a high might pay more attention to criticism than praise. He level of confirmation bias [P5], [P7]. It is supposed that might perceive the meeting as more negative and critical people are more likely to design/run test-cases that would than a similar, healthy developer. In other words, the anx- confirm the expected execution of a program rather than ious person's recurring, self-critical thoughts negatively those test-cases that could identify the failures in a pro- bias his perception of the review. gram [P34]. Debugging activity is also prone to confirma- One primary study ostensibly demonstrated one of the tion bias, therefore, developers should not remain under effects of attentional bias [P30]. Siau et al. investigated ex- the impression that they have located the right cause of a perts' interpretations of entity-relationship diagrams with bug [P34]. conflicts between their relationships and their labels. For 5.2.3 Hyperbolic discounting example, one diagram showed a parent having zero-to- Hyperbolic discounting is the tendency to prefer smaller, many children, when a person obviously needs at least one rewards in the near future over larger rewards later on [69]. child to be a parent. The experts failed to notice these con- It is argued that software designers and managers, due to tradictions because they only attended to the relationships. manifestation of this bias, usually settle for quick-fixes of The study claims that this is "attentional bias"; however, it problems and take resort to simple refactoring, over other does not explain what recurring thoughts were involved, alternatives that might require more effort and planning or how they led to ignoring the surface semantics. This is [P38]. Although, the advantage of quick-fixes requiring another example of confusion in the literature (see Section less effort is more immediate, the implemented solution 6.2). The bias at hand is more likely fixation; the experts' might not be the best solution. analysis was biased by their fixation on one aspect of the models. 5.2.4 Availability bias 5.2.7 Representativeness To mine essential information from software documenta- tion, practitioners tend to search only those locations that The representativeness heuristic is the tendency to make a are either easy to recall or are easily available. However, judgment by fitting an object into a stereotype or model this strategy most often fails to search the correct / re- based on a small number of properties [26]. Due to repre- quired information. Developers even portray a tendency to sentativeness heuristic, people tend to expect results they rely on their past experience which is easily recalled or consider to be representative or typical to a default value available. However, this leads to systemic errors as past an without considering the actual size of the sample.

TABLE 10 ANTECEDENTS OF COGNITIVE BIASES

Cognitive Bias Antecedents Anchoring & Reusing previously written queries; difficult to identify referential points (anchors) [P2]. Adjustment bias Missing, weak and disuse of traceability knowledge [P18], [P19] Recalling domain related information from past knowledge [P19]. Not being able to adjust to the new environment [P21]. Development experience [P17]. Uncertainty of future actions, lack of business knowledge and historical basis and inflexible clients [P65]. Confirmation and availability bias occurrence during system design changes; forming primary understanding of design, requirements and tasks [P18]. Optimism bias Technical roles (project manager, technology developers); effort estimation strategy [P52]. Task difficulty; task size [P54]. Estimates asking format [P49]. Psychologically distant project risks [P25]. Winners curse in project bidding [P61]. Availability bias Prior-knowledge; earlier experience in searching [P14]. Lack of historical records of lessons learned [P65]. Selection of test-cases due to impossibility to perform exhaustive testing [P34]. Confirmation bias Prior-knowledge [P14]. Lack of training in logical reasoning and mathematical proof reading; experience and being active in a role (developer / tester) [P5]. Fixation Framing desiderata as “requirements” [P20]. (Over-) Confidence Inability to question the fundamental way of thinking [P47]. bias Planning fallacy [P47]. Pessimism bias Wrong reporting due to lack of confidence or for acquiring more resources [P33]. Hindsight bias Weak historical basis of lessons learned [P65]. Mere exposure effect A new and different role assignment in a project than before, leaving comfort zone and pessimism about the outcomes of change [P65]. Parkinson’s law Lack of motivation in the case of long duration tasks with poor monitoring of the progress effect [P65]. Halo effect Subjective evaluation criteria being affected by the first impression [P65]. Sunk-cost fallacy Extending the decisions based on immediate benefits without giving due attention to the costs and time required for a change, stubbornness and comfort zone characteristics of project managers [P65].

Similar to availability bias, representativeness bias can members readily agree to the team-leader’s decision with- lead to some code related features to appear more fre- out reconsidering other possible options [P22]. Later, if the quently than the others, which may be in contrast to the chosen possibility leads to unwanted circumstances and actual situation [P34]. Owing to representativeness, a soft- into an overwhelming situation, then the team-members ware tester may choose to disregard a set of error produc- will defend their choices illogically – effect ing test cases that could in turn result in increased defect [P22]. The results of these biased situations may lead to a density [P8]. less liked or a low-quality product because acceptance of the requirements and commending a team-leader for his 5.2.8 Miserly information processing, bandwagon decision is not done diligently.We should, however, cau- effect and status-quo bias tion the reader that these arguments are not backed by em- Miserly information processing is the tendency to avoid pirical observations and come from an opinion article. deep or complex information processing [37]. is, “the propensity for large numbers of individuals, 5.2.9 Overconfidence bias in social and sometimes political situations, to align them- One primary study suggests that overconfidence may selves or their stated opinions with the majority opinion as cause problems in eliciting information from users. Specif- they perceive it” [60, p. 101], and status-quo bias is mani- ically, an overconfident analyst may cease data collection fested when one inclines to a status quo irrationally [71]. before all pertinent information has been found [P4]. Miserly information processing may occur, when a team gathering requirements from the clients readily 5.3 Debiasing approaches agrees with them without any requirements’ reconsidera- The primary studies propose debiasing techniques for only tion [P22]. Bandwagon’s effect may take place when team- 10 of the 47 cognitive biases investigated. However, some

of these techniques target a family of, similar, or interre- in software projects, so several suggestions for debiasing lated biases. This section describes the proposed debiasing expert-based effort estimation have been proposed. approaches for these biases. Table 12 further summarizes For example, planning poker [P40]—an estimation tech- all our findings. Here we must emphasize caution—none nique where participants independently estimate tasks of the primary studies provide strong empirical evidence and simultaneously reveal their estimates—is specifically for the effectiveness of a debiasing techniques. All of the designed to prevent anchoring bias. Because developers proposed techniques are merely suggestions. construct their estimates simultaneously, there is no anchor to adjust. The developers therefore cannot apply the an- 5.3.1 Availability bias choring and adjustment heuristic, and are therefore not For the case where availability bias hindered searching susceptible to anchoring bias. Motivating practitioners to software documentation, three techniques that may miti- explore multiple solutions by simultaneously planning the gate this problem are proposed: developing a “frequently design problem and problem solution (co-evoluation); and asked questions” document, introducing spelling conven- tions, and ontology-based documentation [P14]. Ontology- selecting the best solution option relaxes any dependencies based documentation refers to documents that formalize (anchors) on any implicit constraints due to project-specific multiple relationships between discrete pieces of scattered problems [P35]. information, to traversal and search [P14]. Another sugges- In addition, some have argued that anchoring on an in- tion for mitigating availability bias is to maintain detailed itial estimate can be mitigated by explicitly questioning the records of software practitioners’ gained experience dur- software project managers via different facilitators (project ing software project development lifetime [P55]. members or stakeholders) in a company. In such scenarios, Availability bias also affects software design. Project- knowledge sharing facilitated by team members’ technical specific traceability – a “technique to describe and follow competence helps project managers to avoid anchor their the life of any conceptual or physical software artifact initial estimates based on prior experience or self-assess- throughout the various phases of software development” ments [P67], [P65]. [P18, p. 111], may mitigate not only availability but also an- One study [P39] also suggested warning participants choring bias and confirmation bias [P17], [P18]. Framing about initial estimations and raising awareness about po- the context to highlight relevant information may also help tential bias. However, such weak interventions are un- [P34]. likely to help [39]. Directed questions based approach is Availability bias exacerbates failure rate in software further suggested to mitigate the occurrence of anchoring project management. By explicitly uncovering and explor- bias; for instance: “What is your starting point for estimat- ing new situations and possibilities of cost, time and effort ing (that) duration? Why did you start there?” [P4]. estimation decisions via participatory decision-making, helps to promote retrospective reflection amongst project 5.3.4 Overconfidence and optimism bias participants. This minimizes the possibility of decisions Overconfidence and optimism are two of the most in- made solely on the most recent or available information vestigated cognitive biases in the SE literature (see Fig. 1). [P67], [P65]. Browne and Ramesh propose addressing numerous cogni- tive biases, including overconfidence, using directed ques- 5.3.2 Confirmation bias tions; for instance: “Play the devil's advocate for a minute; Despite being one of the most frequently investigated can you think of any reasons why your solution may be cognitive biases, few techniques for mitigating confirma- wrong?” [P4]. “Directed questions attempt to elicit infor- tion bias have been proposed. Explicitly asking for discon- mation through the use of schemes or checklists designed firmatory evidence against routine guidelines is one ap- to cue information in the user's memory” [P4]. proach [P34]. Similarly, asking designers to generate and Another primary study argues that Planning Poker simultaneously evaluate multiple alternative solutions helps practitioners mitigate optimism [P64]. However, should hinder premature convergence on early confirma- planning poker does not explicitly encourage converging tory evidence [P39]. As discussed in Section 5.3.1, tracea- on more realistic (or pessimistic) estimates. It seems more bility may also help [P17]. plausible that the range of estimates would mitigate over- confidence. 5.3.3 Anchoring and adjustment bias Double-loop learning that involves encouraging indi- Anchoring bias is especially problematic during effort esti- viduals and organizations to engage in self-reflective learn- mation, which is a special case of forecasting. Forecasting ing by explicitly confronting the initial assumptions and is an area of intense study in the operations research com- developing more appropriate ones, is yet another ap- munity; however, this review only covers SE research. Still, proach suggested to mitigate overconfidence bias [P47]. forecasting can be divided into expert-based (i.e., based on Meanwhile, one primary study found that the framing human judgement) and model-based (i.e., based on a of estimation questions affects optimism. Specifically, ask- mathematical model). Since anchoring-and-adjustment ing “How much effort is required to complete X?” pro- only occurs in expert-based forecasting, adopting model- vided less optimistic estimates than asking, “How much based forecasting can be considered a debiasing technique can be completed in Y work hours?” [P49]. Focusing on (with the catch that these models are subject to statistical tasks (rather than time periods) could therefore be consid- bias and variance) [P55], [P65]. However, model-based ered a debiasing technique. forecasting often requires information that is not available

TABLE 11 EFFECTS OF COGNITIVE BIASES

Cognitive Bias Effects Anchoring & Presence of non-required functionality and errors in the final query [P2]. Adjustment bias Presence of non-required functionality and errors in the final solution [P44]. Depleting long term productivity for companies [P53]. Inaccurate adjustments to the system and prototype might sabotage the process of system’s understanding [P4]. Ignorance of the actual change related implementation while accommodating change requests [P19]. Adjusting according to recently exposed knowledge or information [P66]. Confirmation bias False belief about the completeness and correctness of the answer/solution [P14]. Not exploring the system’s implementation completely for dealing with a change request [P19]. Conflicts between technical and non-technical people [P29]. Rejecting results and measurements that do not conform to the analysts beliefs [P39]. Higher defect rate [P5]. Higher number of post-release defects [P7]. Running relatively less number of fault indicating test-cases; wrong impression of finding the right root-cause during debugging [P34]. Desire for a particular result in pilot-runs [P28]. Hyperbolic Putting less effort into fixing and refactoring to have an immediate reward [P38]. discounting Availability bias Ignoring the unfamiliar and less used keywords and locations while seeking for the information in the software documentation [P14]. Relying on easily accessible past experience that might be inconsistent with the current system’s [P18]. Misrepresentation of code features [P34]. Framing effects and Lowering Creativity [P20]. Fixation Attentional Failure in considering alternative possibilities [P30]. Representativeness Misrepresentation of code features [P34]. Possibility of dropping error producing test-cases [P8]. Miserly information Readily agreeing to the client’s requirements without a second thought [P22]. processing Bandwagon effect Readily agreeing with team-leader’s suggestion without a second thought [P22]. Status quo bias Illogical defense of the previously made choices [P22]. Overconfidence bias Effects analyst’s behavior in requirements gathering and causes problems in software development phase [P4].

5.3.5 Representativeness 5.3.6 Hindsight bias Several techniques for mitigating the effects of representa- Hindsight bias can be mitigated by distributing the respon- tiveness are proposed, as follows: sibilities of a software project equally among all the in- • Using consistent user interfaces in decision sup- volved project managers and not overwhelming any spe- port systems [P21]. cific group of managers with critical decision-making re- • Explicitly asking practitioners for alternative solu- sponsibilities [P65]. Hindsight bias can also be mitigated tions (or ideas) [P55]. by maintaining the sequence of software development pro- • Encouraging retrospective analysis and assess- cess activities in a specific order [P65]. ment of practitioners’ judgments [P55]. • Warning practitioners about the bias as a priori 5.3.7 Mere exposure effect (which, again, is unlikely to work) [P55]. Some of the proposed (although not empirically evaluated) • Frequently training the participants to avoid rep- approaches for mitigating mere exposure effect are as fol- resentativeness [P55]. lows [P65]: • Trial and error through pilot tasks during software development processes.

• Explicitly focusing on the final goal or objective of not the same as establishing a significant effect on real pro- a software project during development lifetime. jects. Some biases (e.g. fixation) may completely derail pro- • Involving and considering judgments, opinions, jects (e.g. through complete failure to innovate) while oth- views and concerns of the stakeholders based on ers may have measurable but practically insignificant ef- their knowledge. fects. Measuring effects on key dependent variables of in- terest (e.g. project success) rather than bad proxies (e.g. 5.3.8 Planning fallacy profitability) is essential for differentiating high-impact bi- Planning fallacy is the tendency to underestimate task- ases from low-impact ones. Additionally, better under- completion time based on unrealistic estimates [89]. Few of standing of the mechanisms, through which biases sabo- the techniques for mitigating the effects of planning fallacy tage success, will help us create effective debiasing prac- are proposed, as follows [P65]: tices. • Assessing the progress of all the planned, ongoing Qualitative and exploratory research is needed better to and completed tasks involved in a project on a understand where and how cognitive biases manifest in SE daily basis. practice, and how biases and debiasing techniques are per- • Early involvement of clients and various stake- ceived by practitioners. Multimethodological approaches holders involved in a project during planning, de- may also help. For example, combining a randomized con- velopment and release phase. trol trial with a protocol study may help to not only • Considering stakeholders’ and experts’ judg- demonstrate a causal relationship (experiment) but also re- ments during time estimations based on the past veal the cognitive mechanism underlying the causal rela- knowledge and experience. tionship (protocol study). • Ascertaining flexibility in software project plans. Second, most cognitive biases have not been investi- gated in a software engineering context at all. For instance, 5.3.9 Halo effect the Dunning-Kruger effect is the tendency for less skilled Some of the approaches proposed to mitigate the ill effects people to overestimate their abilities [73]. For example, of halo effect are as follows [65]: suppose a programmer is reviewing a sophisticated code

• Evaluating an artifact or the project participants library. The more skilled the programmer, the more she can on a checklist with the help of other professionals. recognize all of the subtle features of the library: the clean

• By using objective metrics and introducing trans- code, modular architecture, informative comments, clever parency in sharing the personal problems faced use of design patterns, recursion and code-reuse. An in- by all the employees in a company. competent programmer, contrastingly, notices none of 5.3.10 Sunk-cost fallacy these features and simply thinks ‘sure, I could have built this.’ The Dunning-Kruger effect may help to explain con- Sunk-cost fallacy can be mitigated by [65]: flicts between more and less skilled developers, or between • Introducing flexibility and accepting changes and technical and non-technical actors. Collaborative practices alternatives in project plans. including pair programming, peer code review and partic- • Involving stakeholders and experts during project ipative design may ameliorate these conflicts. Of course planning and development phase. this is speculation, but the point is that there are many • Explicitly uncovering the risks involved in vari- more biases, which might help explain important SE phe- ous cost based estimations. nomena, that SE research has not yet investigated. • Organizing team meetings and project demon- Along the same lines, many biases have been investi- strations to update project participants about any gated by only one or two studies. Similarly, several SE updates on a daily basis can even mitigate the knowledge areas are not represented in the sample; that is, manifestation of sunk-cost fallacy. no studies investigate cognitive biases in knowledge areas such as configuration management. Since cognitive biases 6 DISCUSSION are universal human phenomena, some biases likely inter- fere with virtually every aspect of software engineering. 6.1 Implications for Researchers Furthermore, most studies simply demonstrate biases; few This results of this study suggest four ways of improving develop and empirically evaluate debiasing techniques. As research on cognitive biases in SE: conducting more quali- discussed in Section 3, simply warning participants about tative and multimethodological research; integrating re- biases does not work, which makes debiasing techniques sults better across studies; investigating neglected areas; crucial for practical impact. and addressing confusion. Third, research on cognitive biases in SE suffers from the First, experiments are clearly the preferred method in same problems as research on cognitive biases in psychol- our sample. This is appropriate insofar as most of the pri- ogy: most studies are disconnected from each other. This is mary studies investigate causality, rather than establish called the archipelago problem [75]: facts or develop theories. However, it is crucial to better Most of these illusions have been studied in complete isolation without understand not only whether but also how and how much any reference to the other ones …. Experimental methods as well as theoret- cognitive biases affect productivity, quality, and software ical explanations of cognitive illusions thus resemble an archipelago spread engineering success [72]. Demonstrating a bias in a lab is out in a vast ocean

TABLE 12 DEBIASING APPROACHES

Cognitive Bias Debiasing technique / strategy Availability bias Appropriate documentation of information [P14]. Traceability [P18], [P17]. Appropriate framing of information to highlight problematic areas [P34]. Maintaining detailed records [P55]. Participatory retrospective decision-making meetings [P67]. Stakeholders’ judgement and expert involvement [P65]. Confirmation bias Traceability [P17]. Exploring disconfirmatory evidence explicitly [P34]. Generating multiple solutions [P39]. Anchoring / Adjustment bias Traceability [P18], [P17]. Directed-question based approach [P4]. Planning Poker [P40]. Generating multiple solutions [P35]. Increasing awareness of the bias, warning participants, disregarding initial an- chors or status-quo [P39]. Statistical prediction methods [P55]. Technical competence and explicit questioning via facilitators [P67]. Overconfidence bias and opti- Directed-question based approach [P4]. mism bias Planning Poker [P64]. Double-loop cognitive learning [P47]. Appropriately framing estimation questions [P49]. Representativeness Explicitly asking for alternate solutions [P55]. Maintaining consistency in User Interface [P21]. Hindsight bias Distributing equal responsibility among all project managers, Maintaining the software project development process activities [P65]. Mere exposure effect Trial and error through pilot tasks, Explicit focus on the final goal of the project, Stakeholders’ judgment based on their knowledge [P65]. Planning fallacy Daily assessment of planned and accomplished tasks, early involvement of clients in project planning and development, flexibility of project plans, process stand- ardization and stakeholders’ judgment [P65]. Halo effect Evaluation of an artifact / team members with other professionals based on a pre- prepared checklist, using objective metrics and transparency in sharing the per- sonal problems faced by all the employees in a company [P65]. Sunk-Cost fallacy Being flexible and accepting alternative plans, stakeholders’ and expert judg- ments, to uncover the risks involved in cost management, daily team meetings and project demonstrations [P65].

without any sailor having visited more than one (or at the most two) Fourth, research on cognitive biases in SE (and to a of the small islands yet. In trying to further explore this largely un- lesser extent in cognitive psychology) suffers from wide- known territory, we believe that cognitive illusions … should be spread confusion, which we address in the next subsection. placed within the broader context of general cognitive processes. (p. 6.2 Widespread Confusion 399) Analyzing many of the primary studies was hindered Cognitive phenomena rarely act in isolation. Better in- by at least four kinds of confusion. This does not mean that tegrating across studies, biases and knowledge areas may all, or even some, of the primary studies are bad. Rather, be necessary to understand complex cognitive explana- these studies attempt to apply concepts from a social sci- tions for routine SE problems. For example, design creativ- ence discipline to an applied science context, which is often ity is inhibited by the nexus of framing effects, fixation and quite different from the context in which those concepts requirements engineering practices [3]. originated. Communication across scientific communities can be difficult, and some miscommunication is normal

[99]. That said, this subsection attempts to clear up some of This raises the fourth kind of confusion. Since the cog- the more common misunderstandings. nitive mechanisms for many biases are not understood, First, cognitive biases are often confused with related both relationships and distinctions between biases are sus- phenomena such as heuristics and fallacies. pect. For instance, arguing that framing causes fixation is Representativeness and anchoring-and-adjustment are questionable because both the ‘cause’ and ‘effect’ may be heuristics; that is, simple but imperfect rules for judging the same phenomenon in different guises. One primary and deciding. Heuristic reasoning is often correct, but can study addressed this by organizing similar biases into “bi- be biased in specific ways or under specific circumstances. asplexes” [P23] to help reason about debiasing. For example, when estimating using anchoring-and-ad- We have three practical suggestions for addressing justment, we tend to adjust too conservatively. One heuris- these areas of confusion: tic can underlie many biases; for example, the representa- 1. If an SE researcher wishes to use a theory from tiveness heuristic is implicated in several common errors a reference discipline, more extensive reading in probabilistic reasoning. is needed. Appling theories from reference dis- Meanwhile, fallacies are specific errors in logic. For ex- ciplines to new contexts is difficult. Skimming ample, the sunk cost fallacy is a logical error in which past a single paper or Wikipedia article is rarely suf- (lost) investment is used to justify further (irrational) in- ficient preparation. vestment. A fallacy is therefore situated in a specific argu- 2. If possible, collaborating directly with a cogni- ment. In a contrast, we can think of a cognitive bias as a tive psychologist will solve many of these prob- tendency for many people to repeat the same kind of falla- lems. A psychologist is likely not only to have cious argument in different contexts. For example, commit- more background in the underlying theory but ment bias is basically the tendency to make the sunk cost also more training in empirical methods. (We fallacy. discussed aspects of this paper with three dif- To summarize, a cognitive bias is a tendency for differ- ferent professors of psychology to make sure ent people, in different contexts, to experience similar rea- that our interpretations are reasonable and our soning errors. Heuristics are one of several phenomena nomenclature correct.) that cause cognitive biases. Fallacies are one way that some 3. Faced with a manuscript applying a theory cognitive biases manifest in some situations. Cognitive bi- from a reference discipline to SE, editors should ases can be caused by other phenomena, including cogni- consider inviting a review from a member of tive illusions, and can produce other outcomes, including the reference discipline—in this case, a cogni- inaccurate estimates and irrational decisions. tive psychologist. Second, as we saw in Section 5, some primary studies Only seven of the primary studies involved a psycholo- conflate different biases. Specifically, several studies mis- gist in the core research group. More could have consulted characterized a situation in which an actor became unduly psychologists, but collecting that data would require a dif- preoccupied with some artifact, which distorted their be- ferent kind of study. havior. Research on cognitive biases is particularly suscep- tible to this kind of confusion because a host of biases con- 6.3 Implications for Practice cern paying too much attention to some aspects of a situa- The most important take-aways of this research for practi- tion while ignoring others. tioners are as follows: This brings us to the third area of confusion. We noted 1. Cognitive biases are universal human phenomena. above that the problem of using different terms for the They affect everyone and likely have deleterious ef- same bias (e.g. confidence and over-confidence) is more se- fects on all aspects of software development, re- rious than it appears. gardless of industry, platform, programming lan- For example, when we get preoccupied with a number, guage or project management philosophy. it is called anchoring bias. But when we get preoccupied 2. Emails, meetings and otherwise creating awareness with a default option, it is called default bias. We call pre- that our reasoning is biased has no effect on miti- occupation with presentation the framing effect. Preoccu- gating cognitive biases. pation with information that supports our beliefs is confir- 3. Individuals can be debiased, one subject at a time, mation bias, while preoccupation with the typical use of an through extensive (and expensive) training such as object is functional fixedness. Preoccupation with the first that received by meteorologists and actuaries. Most few items in a list is primacy, while preoccupation with computer science and software engineering degrees current conditions is status quo bias. likely do not provide this kind of training. This seems suspicious. All of these biases concern one 4. Alternatively, biases can be mitigated by redesign- aspect of a situation receiving too much attention and sub- ing the person-task system to inhibit the bias (e.g. sequently having too much influence on our reasoning. what Planning Poker does for anchoring bias). Re- Perhaps they are simply different manifestations of the designing the person-task system is the most feasi- same underlying cognitive phenomenon—or perhaps not. ble option for addressing a cognitive bias in most Investigating the neurophysiological underpinnings of organizations. cognitive biases is obviously beyond the scope of SE re- Some (at least potentially) effective debiasing interven- search. tions include:

• Planning poker to prevent anchoring bias in effort ment and stakeholders to deliver faster. Then, specific de- estimation [P40]. biasing techniques—planning poker for anchoring bias • Reference class forecasting or model based fore- and reference class forecasting for optimism bias—can be casting to mitigate optimism in effort estimation described by the instructor and practiced by the students. [P47]. This approach gives students a more nuanced, evidence- • Ontology-based documentation to mitigate avail- based conception of both the problem and potential solu- ability bias [P14]; tions. • Directly asking for disconfirmatory evidence to re- duce confirmation bias [P34]; 6.5 Limitations • Generating multiple, diverse problem formula- The findings of this research should be considered in light tions and solution candidates to mitigate framing of several limitations. effects [P55]. Despite utilizing a very broad search string to search rel- • Using confirmation bias metrics to select less-bi- evant studies from major online databases, employing ased testers [P7]. multi-level retrospective snowballing and authors’ publi- • For security, employ independent penetration cation list analysis, our search might have missed certain testing specialists to reduce confirmation bias [76]. studies concerning cognitive biases in SE; for instance, rel- • Designate or encourage a devil’s advocate in ret- evant studies in other domains including sociology, man- rospective meetings to avoid groupthink [77]. agement science, psychology and investigating cognitive biases in the context of certain SE processes. It is also pos- 6.4 Implications for Education sible that some relevant studies were not indexed in the As explained above, reasoning can be debiased through ex- databases we used. tensive training. What would constitute extensive training We excluded studies that did not explicitly focus on cog- varies depending on the bias. nitive biases; for instance, studies that simply mention the For example, extensive training in effort estimation term cognitive bias but not actually focus the central inves- might consist of estimating several thousand user stories, tigation(s) on cognitive biases. We also excluded studies with immediate, unambiguous feedback. This is probably that considered specific effects or errors caused by cogni- impractical, especially considering the great variety of soft- tive biases, as cognitive biases itself. For instance, studies ware projects and the domain knowledge necessary to es- that considered statistical estimation errors due to opti- timate tasks accurately. mism biases, exclusively as ‘statistical bias’ and ‘estimation However, extensive training in design creativity might bias’. Subjective decisions related to inclusion or exclusion be more practical. For example, consider an assignment of a study was mitigated by involving at least two re- where students have to design a suitable architecture for a searchers during each phase of analysis. given teaching case using UML. Now suppose students are The areas of confusion discussed in Section 6.2 particu- instead asked to design four alternative architectures, all of larly hinder analysis by forcing extra interpretation. which should be reasonable and quite different from each Finally, our recommendations for debiasing SE profes- other. Or, suppose students are asked to design just two ar- sionals are primarily based on suggestions by, not empiri- chitectures, one uncontroversial and one radical. If most cal results of, the primary studies. We simply have insuffi- design-related assignments throughout their degrees call cient empirical research on debiasing to attempt evidence- for multiple alternatives, generating several design candi- based guidelines at this stage. dates will seem natural. Students are thus more likely to carry this practice into their professional work, much like 6.6 Future research the programming styles and testing practices taught today. Section 6.1 suggested four ways of improving research on Implement all of the alternatives is unnecessary. cognitive biases in SE: conducting more qualitative and Whether and how to teach the theory of cognitive biases multimethodological research; integrating results better or particular debiasing techniques is another matter. Ra- across studies; investigating neglected areas and; address- ther than teaching it as a stand-alone topic, it may be more ing confusions around names. We also highlight the bene- efficient to explain many cognitive biases in the context of fits of collaborating with psychologists. common problems and practices. More generally though, this study explores the applica- For example, a usual topic in software project manage- tion of a broad psychological theory to software engineer- ment course is effort estimation. The instructor bemoans ing. Developing an evidenced-based cumulative body of poor effort estimation and explains how Scrum and Ex- knowledge necessitates more such studies focusing on dif- treme Programming prescribe planning poker. The stu- ferent theoretical foundations for SE [78]. dents might then do a planning poker exercise on their term project. This presents planning poker through a 7 CONCLUSION method lens. In contrast, the instructor can present it through a the- This study provides a comprehensive view of research on ory lens. First, we explain the problem (which is readily cognitive biases in software engineering. It identifies 67 understood), followed by the key causes of the problem: 1) primary studies exploring 47 cognitive biases. A constant anchoring bias; 2) optimism bias; 3) pressure from manage- and sustained interest in this area is clear, especially in soft- ware project management. Substantial opportunities for

impactful research remain not only in other areas (e.g. de- terms for the same cognitive biases. Finally, this study also sign, testing, and devops) but also considering other bi- presents the major implications of cognitive biases in SE ases. research, practice and education contributing to cumula- Some of the key findings of this paper are: tive knowledge building. . • Despite SE research focusing on multiple ante- In summary, cognitive biases help to explain many com- cedents and effects of cognitive biases, SE re- mon problems in SE. While they are robust against simply search literature lacks investigations concern- raising awareness, professionals can often be debiased ing antecedents or effects of biases that are sup- through simple interventions. The better we understand ported by credible empirical evidence in hu- the theoretical foundations of common problems and prac- man psychology research, e.g. time-pressure as tices, the easier it will be to develop effective interventions an antecedent to confirmation bias. This highlights to mitigate biases and therefore alleviate their correspond- the negligence of research focused towards cer- ing problems. Ultimately, we hope that this literature re- tain antecedents rooted in human psychology view will encourage many SE researchers to further ex- and critical in SE practice. plore the phenomena of cognitive biases in SE and thus • This study found debiasing approaches for will serve as a base for future research. only 10 cognitive biases. Of which, most of the approaches were situational and context de- References pendent in their nature. [1] M. G. Haselton, D. Nettle, D. R. Murray, M. G. Haselton, D. • The debiasing approaches were not based on Nettle, and D. R. Murray, “The Evolution of Cognitive Bias,” any credible theoretical knowledge from hu- in The Handbook of , Hoboken, NJ, man psychology domain, failing to target spe- USA: John Wiley {&} Sons, Inc., 2015, pp. 1–20. cific or a group of antecedents of biases being [2] D. Arnott, “Cognitive biases and decision support systems addressed.Similarly, in some cases, the pro- development: A design science approach,” Inf. Syst. J., vol. 16, no. 1, pp. 55–78, 2006. posed dibiasing approaches even failed to pro- [3] R. Mohanani, P. Ralph, and B. Shreeve, “Requirements duce effective results. Surprisingly, this study fixation,” in Proceedings of the 36th International Conference on found no evidence of any debiasing ap- Software Engineering - ICSE 2014, 2014, pp. 895–906. proaches towards more robust biases like fixa- [4] A. Tang and Antony, “Software designers, are you biased?,” tion and framing effects. in Proceeding of the 6th international workshop on SHAring and • Although, the investigations reported in pri- Reusing architectural Knowledge - SHARK ’11, 2011, p. 1. mary studies mainly used experiment based re- [5] C. Mair and M. Shepperd, “Human judgement and software search approach, this study found no replica- metrics,” in Proceeding of the 2nd international workshop on tions or family of experiments to further test Emerging trends in software metrics - WETSoM ’11, 2011, p. 81. the effectiveness of debiasing techniques, ef- [6] L. M. Leventhal, B. E. Teasley, and D. S. Rohlman, “Analyses fects of biases or to explore antecedents of bi- of factors related to positive test bias in software testing,” Int. ases in various context or situations during a J. Hum. Comput. Stud., vol. 41, no. 5, pp. 717–749, Nov. 1994. software project lifetime. [7] G. Calikli and A. Bener, “Empirical analyses of the factors • Finally, we noticed that the primary studies affecting confirmation bias and the effects of confirmation were very discrete in nature, i.e., studies did bias on software developer/tester performance,” in not make use of any previously developed Proceedings of the 6th International Conference on Predictive Models in Software Engineering - PROMISE ’10, 2010, p. 1. knowledge and were simply standalone inves- [8] G. J. Browne and V. Ramesh, “Improving information tigations. This might result in studies investi- requirements determination: a cognitive perspective,” Inf. gating same cognitive biases being mostly un- {&} Manag., vol. 39, no. 8, pp. 625–645, 2002. related, or failed to agree on any common un- [9] N. Chotisarn and N. Prompoon, “Forecasting software derstanding of the phenomena of biases in SE. damage rate from cognitive bias in software requirements This study contributes primarily by providing a com- gathering and specification process,” in 2013 IEEE Third prehensive view of the antecedents to cognitive biases in International Conference on Information Science and Technology SE, their effects and various debiasing techniques de- (ICIST), 2013, pp. 951–956. ployed to counter the harmful effects of cognitive biases in [10] M. Jorgensen and S. Grimstad, “Software Development SE practices. Although, much evidence based research con- Estimation Biases: The Role of Interdependence,” IEEE centrated to study the antecedents and effects of cognitive Trans. Softw. Eng., vol. 38, no. 3, pp. 677–693, May 2012. biases in SE practices, there exists acute shortage of empir- [11] V. A. Gheorghiu, G. Molz, and R. Pohl, “Suggestions and ical research investigating the effectiveness of debiasing illusions,” 2004. practices. Inspite of literature recognizing 47 cognitive bi- [12] P. Ralph, “Toward a Theory of Debiasing Software ases in play, most of the mainstream research is concen- Development,” Springer, Berlin, Heidelberg, 2011, pp. 92– 105. trated only towards 10-12 biases. This study also highlights [13] M. Fleischmann, M. Amirpur, A. Benlian, and T. Hess, the widespread areas of confusion concerning the psycho- “Cognitive Biases in Information Systems Research: a logical nomenclature, distorted conceptualization of cer- Scientometric Analysis,” ECIS 2014 Proc., no. 26, pp. 1–21, tain cognitive biases based on different situational aspects, 2014. truncated understanding of various underlying cognitive [14] A. P. Sage and W. B. Rouse, Handbook of systems engineering mechanisms triggering biases and research using different and management. J. Wiley {&} Sons, 1999.

[15] C. E. Zsambok and G. Klein, Naturalistic Decision Making. trackers, lemmings and the lost: Sustained false optimism in Taylor and Francis, 2014. forecasting project outcomes — Evidence from a quasi- [16] C. R. B. de Souza, H. Sharp, J. Singer, L.-T. Cheng, and G. experiment,” Int. J. Proj. Manag., vol. 29, no. 8, pp. 1070–1081, Venolia, “Guest Editors’ Introduction: Cooperative and 2011. Human Aspects of Software Engineering,” IEEE Softw., vol. [36] B. Flyvbjerg and Bent, “From Nobel Prize to Project 26, no. 6, pp. 17–19, Nov. 2009. Management: Getting Risks Right,” eprint arXiv:1302.3642, [17] G. M. Weinberg, The psychology of computer programming. Feb. 2013. Dorset House Pub, 1998. [37] Stanovich and K. E., What intelligence tests miss: The [18] D. Arnott and G. Pervan, “Eight key issues for the decision psychology of rational thought. Yale University Press, 2009. support systems discipline,” Decis. Support Syst., vol. 44, no. [38] P. Ralph and R. Mohanani, “Is requirements engineering 3, pp. 657–672, 2008. inherently counterproductive?,” Proceedings of the Fifth [19] A. P. Snow, M. Keil, and L. Wallace, “The effects of optimistic International Workshop on Twin Peaks of Requirements and and pessimistic biasing on software project status Architecture. IEEE Press, pp. 20–23, 2015. reporting,” Inf. {&} Manag., vol. 44, no. 2, pp. 130–141, 2007. [39] B. Fischoff, “Debiasing,” in Judgment under Uncertainty: [20] J. Parsons and C. Saunders, “Cognitive heuristics in software Heuristics and Biases, D. Kahneman, P. Slovic, and A. Tversky, engineering applying and extending anchoring and Eds. Cambridge, USA: Cambridge University Press, 1982. adjustment to artifact reuse,” IEEE Trans. Softw. Eng., vol. 30, [40] R. P. Larrick, “Debiasing,” in Blackwell handbook of judgment no. 12, pp. 873–888, Dec. 2004. and decision making, John Wiley {&} Sons, 2008. [21] W. Stacy and J. MacMillan, “Cognitive bias in software [41] E. Pronin, D. Y. Lin, and L. Ross, “The : engineering,” Commun. ACM, vol. 38, no. 6, pp. 57–63, Jun. Perceptions of Bias in Self Versus Others,” Personal. Soc. 1995. Psychol. Bull., vol. 28, no. 3, pp. 369–381, Mar. 2002. [22] T. Hall, N. Baddoo, S. Beecham, H. Robinson, and H. Sharp, [42] E. Pronin, “Perception and misperception of bias in human “A systematic review of theory use in studies investigating judgment,” Trends Cogn. Sci., vol. 11, no. 1, pp. 37–43, 2007. the motivations of software engineers,” ACM Trans. Softw. [43] N. C. Haugen, “An empirical study of using planning poker Eng. Methodol., vol. 18, no. 3, pp. 1–29, May 2009. for user story estimation,” in Proceedings - AGILE Conference, [23] S. S. J. O. Cruz, F. Q. B. da Silva, C. V. F. Monteiro, C. F. 2006, 2006. Santos, and M. T. dos Santos, “Personality in software [44] D. Budgen, D. Budgen, M. Turner, P. Brereton, and B. engineering: preliminary findings from a systematic Kitchenham, “Using Mapping Studies in Software literature review,” in 15th Annual Conference on Evaluation {&} Engineering.” Assessment in Software Engineering (EASE 2011), 2011, pp. 1– [45] K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson, 10. “Systematic mapping studies in software engineering,” [24] D. E. Leidner and T. Kayworth, “Review: a review of culture EASE’08 Proc. 12th Int. Conf. Eval. Assess. Softw. Eng., pp. 68– in information systems research: toward a theory of 77, 2008. information technology culture conflict,” MIS Q., vol. 30, no. [46] B. Kitchenham and S. Charters, “Guidelines for performing 2, pp. 357–399, 2006. Systematic Literature Reviews in Software Engineering,” [25] P. Lenberg, R. Feldt, and L. G. Wallgren, “Behavioral Engineering, 2007. software engineering: A definition and systematic literature [47] G. H. Travassos, P. S. M. dos Santos, P. G. Mian, A. C. D. review,” J. Syst. Softw., vol. 107, pp. 15–37, 2015. Neto, and J. Biolchini, “An Environment to Support Large [26] A. Tversky and D. Kahneman, “Judgment under Scale Experimentation in Software Engineering,” in 13th Uncertainty: Heuristics and Biases,” in Utility, Probability, IEEE International Conference on Engineering of Complex and Human Decision Making, Dordrecht: Springer Computer Systems (iceccs 2008), 2008, pp. 193–202. Netherlands, 1975, pp. 141–162. [48] B. Kitchenham, “What’s up with software metrics? – A [27] T. (Ed) Gilovich, D. (Ed) Griffin, and D. (Ed) Kahneman, preliminary mapping study,” J. Syst. Softw., vol. 83, no. 1, pp. Heuristics and Biases. Cambridge: Cambridge University 37–51, 2010. Press, 2002. [49] B. Kitchenham, R. Pretorius, D. Budgen, O. Pearl Brereton, [28] G. B. Chapman and A. S. Elstein, “Cognitive processes and M. Turner, M. Niazi, and S. Linkman, “Systematic literature biases in medical decision making.” 2000. reviews in software engineering – A tertiary study,” Inf. [29] A. Shleifer, “Psychologists at the Gate: A Review of Daniel Softw. Technol., vol. 52, no. 8, pp. 792–805, 2010. Kahneman’s Thinking, Fast and Slow,” J. Econ. Lit., vol. 50, [50] D. Budgen, A. J. Burn, O. P. Brereton, B. A. Kitchenham, and no. 4, pp. 1080–1091, Dec. 2012. R. Pretorius, “Empirical evidence about the UML: a [30] R. Pohl, Cognitive illusions: a handbook on fallacies and biases systematic literature review,” Softw. Pract. Exp., vol. 41, no. in thinking, judgement and memory. Psychology Press, 2004. 4, pp. 363–392, Apr. 2011. [31] E. J. Langer and E. J., “The illusion of control.,” J. Pers. Soc. [51] F. W. Neiva, J. M. N. David, R. Braga, and F. Campos, Psychol., vol. 32, no. 2, pp. 311–328, 1975. “Towards pragmatic interoperability to support [32] I. L. Janis, Groupthink: psychological studies of policy decisions collaboration: A systematic review and mapping of the and fiascoes. Houghton Mifflin, 1982. literature,” Inf. Softw. Technol., vol. 72, pp. 137–150, 2016. [33] A. Wilke and R. Mata, “Cognitive Bias,” in Encyclopedia of [52] V. R. Basili, G. Caldiera, and D. H. Rombach, “The Goal Human Behavior, Elsevier, 2012, pp. 531–535. Question Metric Approach,” Encycl. Softw. Eng., vol. 1, 1994. [34] G. Calikli and A. Bener, “Preliminary analysis of the effects [53] I. Steinmacher, A. P. Chaves, and M. A. Gerosa, “Awareness of confirmation bias on software defect density,” in Support in Distributed Software Development: A Systematic Proceedings of the 2010 ACM-IEEE International Symposium on Review and Mapping of the Literature,” Comput. Support. Empirical Software Engineering and Measurement - ESEM ’10, Coop. Work, vol. 22, no. 2–3, pp. 113–158, Apr. 2013. 2010, p. 1. [54] P. A. Laplante, What every engineer should know about software [35] E. Kutsch, H. Maylor, B. Weyer, and J. Lupson, “Performers, engineering. Taylor {&} Francis, 2007.

[55] J. Cohen and Jacob, “Weighted kappa: Nominal scale Illusion,” in Cognitive illusions: a handbook on fallacies and agreement provision for scaled disagreement or partial biases in thinking, judgement and memory, R. Pohl, Ed. credit.,” Psychol. Bull., vol. 70, no. 4, pp. 213–220, 1968. Psychology Press, 2004, pp. 399–421. [56] T. Dyba, T. Dingsoyr, and G. K. Hanssen, “Applying [76] B. Arkin, S. Stender, and G. McGraw, “Software penetration Systematic Reviews to Diverse Study Types: An Experience testing,” IEEE Security and Privacy. 2005. Report,” in First International Symposium on Empirical Software [77] C. MacDougall and F. Baum, “The Devil’s Advocate: A Engineering and Measurement (ESEM 2007), 2007, pp. 225–234. Strategy to Avoid Groupthink and Stimulate Discussion in [57] M. Ivarsson and T. Gorschek, “A method for evaluating rigor Focus Groups,” Qual. Health Res., 1997. and industrial relevance of technology evaluations,” Empir. [78] P. Ralph, M. Chiasson, and H. Kelley, “Social theory for Softw. Eng., vol. 16, no. 3, pp. 365–395, Jun. 2011. software engineering research,” in ACM International [58] B. Kitchenham, “Procedures for Performing Systematic Conference Proceeding Series, 2016. Reviews,” 2004. [79] M. E. Oswald and S. Grosjean, “Confirmation Bias,” in [59] A. Abran, J. W. Moore, P. Bourque, R. Dupuis, and L. L. Cognitive illusions: A handbook on fallacies and biases in thinking, Tripp, Guide to the Software Engineering Body of Knowledge, vol. Judgement and Memory, Hove, UK: Psychology Press, 2004, 19759, no. 6. 2004. pp. 79–96. [60] VandenBos and G. R. (Ed), APA Dictionary of Psychology. [80] Plous and Scott, The psychology of judgment and decision American Psychological Association, 2007. making. Mcgraw-Hill Book Company, 1993. [61] R. A. Baron, “The cognitive perspective: a valuable tool for [81] I. Watson, A. Basden, and P. Brandon, “The client-centred answering entrepreneurship’s basic ‘why’ questions,” J. Bus. approach: expert system development,” Expert Syst., vol. 9, Ventur., vol. 19, no. 2, pp. 221–239, 2004. no. 4, pp. 181–188, Nov. 1992. [62] R. M. Poses and M. Anthony, “Availability, Wishful [82] A. Colman, A dictionary of psychology. Oxford, UK: Oxford Thinking, and Physicians’ Diagnostic Judgments for Patients University Press, 2009. with Suspected Bacteremia,” Med. Decis. Mak., vol. 11, no. 3, [83] D. G. Jansson and S. M. Smith, “Design fixation,” Des. Stud., pp. 159–168, Aug. 1991. vol. 12, no. 1, pp. 3–11, Jan. 1991. [63] M. Nurminen, P. Suominen, S. Äyrämö, and T. Kärkkäinen, [84] H. Schwartz, “Predictably Irrational: the hidden forces that “Applying Semiautomatic Generation of Conceptual Models shape our decisions,” Bus. Econ., vol. 43, no. 4, pp. 69–72, to Decision Support Systems Domain,” Software Engineering. 2008. ACTA Press. [85] E. D. Smith, Y. J. Son, M. Piattelli-Palmarini, and A. Terry [64] M. R. Leary, “Hindsight Distortion and the 1980 Presidential Bahill, “Ameliorating mental mistakes in tradeoff studies,” Election,” Personal. Soc. Psychol. Bull., vol. 8, no. 2, pp. 257– Syst. Eng., vol. 10, no. 3, pp. 222–240, 2007. 263, Jun. 1982. [86] A. Madni, “The Role of Human Factors in Expert Systems [65] J. A. O. G. da Cunha, F. Q. B. da Silva, H. P. de Moura, and Design and Acceptance,” Hum. Factors, vol. 30, no. 4, pp. 395– F. J. S. Vasconcellos, “Decision-making in software project 414, 1988. management,” in Proceedings of the 9th International Workshop [87] R. Bornstein and C. Carver-Lemley, “Mere Exposure Effect,” on Cooperative and Human Aspects of Software Engineering - in Cognitive Illusions: A Handbook on Fallacies and Biases in CHASE ’16, 2016, pp. 26–32. Thinking, Judgement and Memory, Hove, UK: Psychology [66] C. N. Parkinson and O. Lancaster, “Parkinson’s law, or The Press, 2004, pp. 215–234. pursuit of progress,” 2011. [88] B. Robinson-Riegler and G. L. Robinson-Riegler, Cognitive [67] E. Long-Crowell, “The Halo Effect: Definition, Advantages & psychology: Applying the science of the Mind. Pearson, 2004. Disadvantages,” in Psychology, 2015, p. 104. [89] L. J. Sanna and N. Schwarz, “Integrating temporal biases: [68] H. R. Arkes and P. Ayton, “The sunk cost and Concorde The interplay of focal thoughts and accessibility effects: Are humans less rational than lower animals?,” experiences,” Psychol. Sci., vol. 15, no. 7, pp. 474–481, Jul. Psychol. Bull., vol. 125, no. 5, p. 591, 1999. 2004. [69] R. J. Wirfs-Brock, “Giving Design Advice,” IEEE Softw., vol. [90] H. Omer and N. Alon, “The continuity principle: A unified 24, no. 4, pp. 13–15, Jul. 2007. approach to disaster and trauma,” Am. J. Community Psychol., [70] Y. Bar-Haim, D. Lamy, L. Pergamin, M. J. Bakermans- vol. 22, no. 2, pp. 273–287, Apr. 1994. Kranenburg, and M. H. van IJzendoorn, “Threat-related [91] L. A. Granka, “The Politics of Search: A Decade attentional bias in anxious and nonanxious individuals: A Retrospective,” Inf. Soc., vol. 26, no. 5, pp. 364–374, Sep. 2010. meta-analytic study.,” Psychol. Bull., vol. 133, no. 1, pp. 1–24, [92] B. Shore, “Systematic biases and culture in project failures,” Jan. 2007. Proj. Manag. J., vol. 39, no. 4, pp. 5–16, Nov. 2008. [71] W. Samuelson and R. Zeckhauser, “Status quo bias in [93] D. T. Gilbert, E. C. Pinel, T. D. Wilson, S. J. Blumberg, and T. decision making,” J. Risk Uncertain., vol. 1, no. 1, pp. 7–59, P. Wheatley, “Immune neglect: A source of durability bias in Mar. 1988. affective forecasting.,” J. Pers. Soc. Psychol., vol. 75, no. 3, pp. [72] P. Ralph and P. Kelly, “The dimensions of software 617–638, 1998. engineering success,” in Proceedings of the 36th International [94] J. T. Jost and M. R. Banaji, “The role of stereotyping in Conference on Software Engineering - ICSE 2014, 2014, pp. 24– system-justification and the production of false 35. consciousness,” Br. J. Soc. Psychol., vol. 33, no. 1, pp. 1–27, [73] J. Kruger and D. Dunning, “Unskilled and unaware of it: Mar. 1994. How difficulties in recognizing one’s own incompetence [95] E. Bozdag, “Bias in algorithmic filtering and lead to inflated self-assessments.,” J. Pers. Soc. Psychol., 1999. personalization,” Ethics Inf. Technol., vol. 15, no. 3, pp. 209– [74] K. Koffka, “Principles of gestalt psychology Chapter I Why 227, Sep. 2013. Psychology? An introductory question,” Princ. Gestalt [96] C. R. Kenley and D. C. Armstead, “Discounting models for Psychol., pp. 1–14, 1935. long-term decision making,” Syst. Eng., vol. 7, no. 1, pp. 13– [75] V. Gheorghiu, G. Molz, and R. Pohl, “Suggestion and 24, 2004.

[97] N. Taylor, “Making actuaries aess human: Lessons from behavioural finance,” Staple Inn Actuar. Soc. Meet., 2000. [98] B. R. Forer and B. R., “The fallacy of personal validation: a classroom demonstration of gullibility.,” J. Abnorm. Soc. Psychol., vol. 44, no. 1, pp. 118–123, 1949. [99] T. S. Kuhn, "The Structure of Scientific Revolutions", 2nd enl. ed. University of Chicago Press.

APPENDIX A: DEFINITIONS OF COGNITIVE BIASES INVESTIGATED IN SE

Cognitive bias Definition Primary studies Anchoring (and adjustment) “The tendency, in forming perceptions or making quantitative judgments of some entity under P1, P2, P8, P11, P12, P17, P18, P19, P21, P23, bias conditions of uncertainty, to give excessive weight to the initial starting value (or anchor), P32, P36, P62, P55, P49, P44, P35, P59, P58, based on the first received information or one’s initial judgment, and not to modify this anchor P40, P39, P53, P51, P45, P67, P66, P65 sufficiently in light of later information” [60, p. 51]. Adjustment bias is a psychological ten- dency that influences the way people intuitively assess probabilities [26]. Attentional bias The tendency of our perception to be affected by our recurring thoughts [70]. P30, P42 Availability bias Availability bias refers to a tendency of being influenced by the information that is easy to recall P8, P11, P12, P14, P18, P19, P24, P31, P41, and by the information that is recent or widely publicized [62]. P45, P39, P62, P34, P17, P66, P67, P65 Bandwagon effect “The tendency for large numbers of individuals, in social and sometimes political situations, P22, P23 to align themselves or their stated opinions with the majority opinion as they perceive it” [60, p. 101]. Belief perseverance “The tendency to maintain a belief even after the information that originally gave rise to it has P23, P29 been refuted or otherwise shown to be inaccurate” [60, p. 112]. (Over-)confidence bias The tendency to overestimate one’s own skill, accuracy and control over one’s self and envi- P17, P21, P43, P4, P39, P47 ronment [63]. Confirmation bias The tendency to search for, interpret, focus on and remember information in a way that con- P5, P6, P7, P8, P9, P10, P11, P13, P14, P15, firms one's preconceptions [79]. P17, P18, P19, P21, P22, P28, P32, P41, P45, P46, P39, P57, P38, P34, P66 Contrast effect The enhancement or reduction of a certain perception's stimuli when compared with a recently P38 observed, contrasting object [80]. Default bias The tendency to choose preselected options over superior, unselected options [71]. P23 End-user bias End-user bias occurs when there is a mismatch between the developer and end-user’s concep- P27 tualizations of the subject matter domain [81]. “The tendency to demand much more to give up an object than one is willing to pay to acquire P26 it” [82]. Fixation The tendency to disproportionately focus on one aspect of an event, object, or situation, espe- P20 cially self-imposed or imaginary obstacles [83]. Framing effect “The tendency to give different responses to problems that have surface dissimilarities but that P20, P21, P66 are really formally identical” [37] Halo effect The halo effect can be defined as the tendency to use global evaluations to make judgments P37, P65 about specific traits [67]. Hindsight bias When people know the actual outcome of a process, they tend to regard that outcome as having P59, P62, P51, P65 been fairly predictable all along – or at least more predictable than they would have judged before knowing the outcome [64]. Hyperbolic discounting The tendency of people to prefer options that offer smaller rewards with more immediate pay- P38 off to options with larger rewards promised for future [69]. IKEA effect / I-designed-it- The IKEA effect depicts how object valuation increases when that object has been self-created P26 myself effect [63].

Information bias The strong tendency to ask for more additional information, especially in times of uncertainty P11, P16, P27, P29, P38 [68]. The location and availability of preexisting infrastructure such as roads and telecommunica- P39 tion facilities influences future economic and social development [84]. Invincibility bias The tendency to over trust one’s own abilities [84]. P39 Knowledge engineer As the knowledge-engineer (KE) becomes familiar with the problem domain, a mental frame- P27 work takes shape resulting into a mismatch [85]. Mere exposure effect “Increased liking for a stimulus that follows repeated, unreinforced exposure to that stimulus” P23, P65, P67 [86, p. 31]. Miserly information pro- The tendency to avoid deep or complex information processing [37]. P22 cessing Misleading information The tendency to blindly follow the provided information without being able to self-evaluate P22, P59, P51 [87]. Neglect of probability The tendency to discount any risks that people perceive as being less than certain [88]. P38 Normalcy effects Systematically “underestimating the probability or extent of expected disruption” during a P23 disaster” [61]. (Over-)optimism bias The tendency to be over-optimistic, overestimating favorable and pleasing outcomes [88]. P48, P59, P47, P23, P25, P33, P60, P61, P56, P64, P63, P52, P53, P50, P54 Parkinson’s Law effect Human tendency to procrastinate the execution of activities until the end date originally P65 agreed [66]. Pessimism bias The tendency to report the status of any task in worse shape than the actual reality [19]. P33, P59 Planning fallacy The tendency to underestimate task-completion time [89]. P47, P65 Popularity bias The tendency to choose options that are socially or empirically more popular than other op- P3 tions [90]. Primacy and recency effects The tendency of people to remember the first and the last few items more than those in the P38 middle [69]. Representativeness The tendency in which a person reduces many inferential tasks to simple similarity judgements P8, P31, P34, P62, P55, P45 [26]. Selective perception The tendency to perceive events differently by different people [80]. P62 Semantic fallacy The tendency to ignore the underlying semantics depicted by the information models and fo- P42 cus mainly on the structural constraints given, even for models that had obvious contradiction between the structural constraints and the underlying semantics [26]. Semmelweis reflex Unthinking rejection of new information that contradicts established beliefs or paradigms [91]. P23 Sequence impact Sequence impact is the tendency for people to overestimate the length or the intensity of future P59, P51 feeling states [92]. Situation bias The human tendency to follow a previous course of action, only because it was used previously P21 [2]. Status quo bias / System jus- The tendency to irrationally prefer, maintain and defend current conditions, operating proce- P22, P23, P39 tification dures, status, or social order [93]. Subject-matter expert The tendency of a decision-maker to influence the final outcome of the decision process, typi- P27 cally at higher levels in management hierarchy [62].

Sunk cost fallacy The sunk-cost fallacy is a decision-making bias that reflects the tendency to invest more future P65 resources in a situation in which a prior investment has been made, as compared with a similar situation in which a prior investment has not been made [68]. Technical bias The bias caused by third party manipulation or popularity of certain individual factors such P3 as personal judgments, organizational factors such as company policies and external factors such as advertiser requests [94]. Time based bias Time-based bias involves a reduction of attention via short-term thinking and hyperbolic dis- P32, P38 counting errors [95]. Valence effect The tendency to give undue weight to the degree to which an outcome is considered as positive P23 or negative when estimating the probability of its occurrence [96]. Validation bias The tendency in which a person will consider a statement or another piece of information to P27 be correct if it has any personal meaning or significance to them [97]. Validity effect “The validity effect occurs when the mere repetition of information affects the perceived truth- P23 fulness of that information the validity effect occurs similarly for statements of fact that are true and false in origin, as well as political or opinion statements” [98, p. 211]. Wishful thinking The tendency to underestimate the likelihood of a negative outcome and vice versa [62]. P23, P51, P59

no. 9, pp. 1407-1426, 2013. [P17] R. Jain, J. Muro, and K. Mohan, “A cognitive perspective on pair APPENDIX B: LIST OF PRIMARY STUDIES programming”. In Proceedings of AMCIS, pp. 444, 2006. [P1] G. Allen and J. Parsons, “Is query reuse potentially harmful? An- [P18] K. Mohan, and R. Jain, “Using traceability to mitigate cognitive choring and adjustment in adapting existing database queries”, biases in software development”, Communications of the ACM, Information Systems Research, vol. 21, no. 1, pp. 56-77, 2010. vol. 51, no. 9, pp. 110-114, 2008. [P2] G. Allen and B. J. Parsons, “A little help can be a bad thing: An- [P19] K. Mohan, N. Kumar, and R. Benbunan-Fich, “Examining com- choring and adjustment in adaptive query reuse”. Proceedings of munication media selection and information processing in soft- ICIS 2006, vol. 45, 2006. ware development traceability: An empirical investigation”. [P3] E. Bozdag, “Bias in algorithmic filtering and personalization”, IEEE Transactions on Professional Communication, vol. 52, no. 1, Ethics and Information Technology, vol. 15, no. 3, pp. 209-227, pp. 17-39, 2009. 2013. [P20] R. Mohanani, P. Ralph, and B. Shreeve, “Requirements fixation”, [P4] G. J. Browne and V. Ramesh, “Improving information require- In Proceedings of the 36th International Conference on Software En- ments determination: a cognitive perspective”, Information & gineering, pp. 895-906, May 2014. Management, vol. 39, no. 8, pp. 625-645, 2002. [P21] M. Nurminen, P. Suominen, S. Äyrämö, and T. Kärkkäinen,”Ap- [P5] G. Calikli, and A. Bener, “Empirical analyses of the factors affect- plying semiautomatic generation of conceptual models to deci- ing confirmation bias and the effects of confirmation bias on sion support systems domain”, In Proceedings of the IASTED In- software developer/tester performance”. Proceedings of the 6th ternational Conference on Software Engineering, ACTA Press, 2009. International Conference on Predictive Models in Software Engineer- [P22] P. Ralph, “Possible core theories for software engineering”. In ing, pp. 10, September 2010. 2nd Workshop on a General Theory of Software Engineering, pp. 35- [P6] G. Calikli, A. Bener, and B. Arslan, “An analysis of the effects of 38, May 2013. company culture, education and experience on confirmation [P23] P. Ralph, “Toward a theory of debiasing software develop- bias levels of software developers and testers”, Proceedings of the ment”, “In EuroSymposium on Systems Analysis and Design, 32nd ACM/IEEE International Conference on Software Engineering, Springer Berlin Heidelberg, pp. 92-105, 2011. vol. 2, pp. 187-190, May 2010. [P24] J. E. Robbins, D. M. Hilbert, and D. F. Redmiles, “Software ar- [P7] G. Calikli, A. Bener, T. Aytac, and O. Bozcan, “Towards a metric chitecture critics in Argo”, In Proceedings of the 3rd International suite proposal to quantify confirmation biases of developers”. Conference on Intelligent User Interfaces, pp. 141-144, January in 2013 ACM/IEEE International Symposium on Empirical Software 1998. Engineering and Measurement, pp. 363-372, October 2013. [P25] E. Shalev, M. Keil, J. S. Lee, and Y. Ganzach, “Optimism Bias in [P8] G. Calikli, A. Bener, B. Caglayan, and A. T. Misirli, “Modeling managing IT project risks: A construal level theory perspec- Human Aspects to Enhance Software Quality Management”, In tive”, In Proceedings of 22nd European Conference on Information Proceedings of 33rd International Conference on Information Systems, Systems, 2014. 2012. [P26] O. Shmueli, N. Pliskin, and L.Fink,”Explaining over-require- [P9] G. Calikli and A. B. Bener, “Influence of confirmation biases of ment in software development projects: an experimental inves- developers on software quality: an empirical study”. Software tigation of behavioral effects”. International Journal of Project Quality Journal, vol. 21, no. 2, pp. 377-416, 2013. Management, vol. 33, no. 2, pp. 380-394, 2015. [P10] G. Calikli and A. Bener, “An algorithmic approach to missing [P27] B. Shore, “Bias in the development and use of an expert system: data problem in modeling human aspects in software develop- Implications for life cycle costs”. Industrial Management & Data ment”, In Proceedings of the 9th International Conference on Predic- Systems, vol. 96, no. 4, pp. 18-26, 1996. tive Models in Software Engineering, pp. October 2013. [P28] F. Shull, “Engineering values: From architecture games to agile [P11] N. Chotisarn and N. Prompoon, “Forecasting software damage requirements”. IEEE Software, vol. 30, no. 2, pp. 2-6, 2013. rate from cognitive bias in software requirements gathering and [P29] F. Shull, “Our Best Hope”, IEEE Software, vol. 31, no. 4, pp. 4-8, specification process”. In 2013 IEEE Third International Confer- 2014. ence on Information Science and Technology (ICIST), pp. 951-956, [P30] K. Siau, Y. Wand, and I. Benbasat, “The relative importance of March 2013. structural constraints and surface semantics in information [P12] N. Chotisarn and N. Prompoon, “Predicting Software Damage modeling”. Information Systems, vol. 22, no. 2, pp. 155-170, 1997. Rate from Cognitive Bias in Software Design Process”. In Pro- [P31] B. G. Silverman, “Critiquing human judgment using ceedings of the 2013 International Conference on Information, Busi- knowledge-acquisition systems”, AI Magazine, vol. 11, no. 3, pp. ness and Education Technology (ICIBET 2013). Atlantis Press, 60, 1990. March 2013. [P32] E. D. Smith and B. A. Terry, “ in systems [P13] P. Conroy and P. Kruchten, “Performance norms: An approach engineering”. Systems engineering, vol. 13, no. 2, pp. 130-148, to rework reduction in software development”. In 25th IEEE Ca- 2010. nadian Conference on Electrical & Computer Engineering (CCECE), [P33] A. P. Snow, M. Keil, and L. Wallace, “The effects of optimistic pp. 1-6, 2012. and pessimistic biasing on software project status reporting”. [P14] K. A. de Graaf, P. Liang, A. Tang, and H. van Vliet, “The impact Information & Management, vol. 44, no. 2, pp. 130-141, 2007. of prior knowledge on searching in software documentation”. [P34] W. Stacy and J. MacMillan, “Cognitive bias in software engi- In Proceedings of the 2014 ACM symposium on Document engineer- neering”. Communications of the ACM, vol. 38, no. 6, pp. 57-63, ing. pp. 189-198, September 2014. 1995. [P15] J. Defranco-tommarello and F. P. Deek, “Collaborative problem [P35] A. Tang, “Software designers, are you biased?”. In Proceedings of solving and groupware for software development”, Information the 6th International Workshop on Sharing and Reusing Architec- Systems Management, vol. 21, no. 1, pp. 67-80, 2004. DOI: tural Knowledge, pp. 1-8, May 2011. 10.1201/1078/43877.21.1.20041201/78987.7 [P36] A. Tang, and M. F. Lau, “Software architecture review by asso- [P16] I. Hadar, “When intuition and logic clash: The case of the object- ciation”, Journal of Systems and Software, vol. 88, pp. 87-101, 2014. oriented paradigm”. Science of Computer Programming, vol. 78, [P37] P. Tobias, D. S. Spiegel, “Is Design the Preeminent Protagonist

in User Experience?”, Ubiquity, May 2009. human judgement heuristics”, Scandinavian Journal of Infor- [P38] R. J. Wirfs-Brock, “Giving Design Advice”. IEEE Software, vol. mation Systems, vol. 13, no. 1, pp. 2, 2001. 24, no. 4, pp. 13-15, 2007. [P56] K. Moløkken-Østvold and M. Jørgensen, “Group processes in [P39] E. D. Smith, Y. J. Son, M. Piattelli-Palmarini, and A. T. Bahill, software effort estimation”, Empirical Software Engineering, vol. “Ameliorating mental mistakes in tradeoff studies”. Systems En- 9, no. 4, pp. 315-334, 2004. gineering, vol. 10, no. 3, 2007. [P57] G. Calikli and A. Bener, “Preliminary analysis of the effects of [P40] N. C. Haugen, “An empirical study of using planning poker for confirmation bias on software defect density”, In Proceedings of user story estimation”. In AGILE 2006 (AGILE'06), pp. 9-pp, July 4th International Symposium on Empirical Software Engineering and 2006. Measurement, 2010. [P41] A. J. Ko and B. A. Myers, “A framework and methodology for [P58] E. Løhre and M. Jørgensen, “Numerical anchors and their strong studying the causes of software errors in programming sys- effects on software development effort estimates”, Journal of tems”. Journal of Visual Languages & Computing, vol. 16, no. 1, pp. Systems and Software, vol. 116, pp. 49-56, 2016. 41-84, 2005. [P59] M. Jørgensen and B. Faugli, “Prediction of overoptimistic pre- [P42] K. Siau, Y. Wand, and I. Benbasat, “When parents need not have dictions”, In Proceedings of 10th International Conference on Eval- children—Cognitive biases in information modeling”. In Inter- uation and Assessment in Software Engineering, British Computer national Conference on Advanced Information Systems Engineering, Society, 2006. pp. 402-420, May 1996. [P60] M. Jørgensen and Gruschke, “Industrial use of formal software [P43] S. Chakraborty, S. Sarker, and S. Sarker, “An exploration into cost estimation models: Expert estimation in disguise?”, In Pro- the process of requirements elicitation: A grounded approach”, ceedings of Conference on Evaluation and Assessment in Software En- Journal of the Association for Information Systems, vol. 11, no. 4, pp. gineering (EASE’05), pp. 1-7, 2005. 212, 2010. [P61] M. Jorgensen and S. Grimstad, “Over-Optimism in Software De- [P44] J. Parsons and C. Saunders, “Cognitive heuristics in software velopment Projects:" The Winner’s Curse", In 15th International engineering applying and extending anchoring and adjustment Conference on Electronics, Communications and Computers (CO- to artifact reuse”, IEEE Transactions on Software Engineering, vol. NIELECOMP'05), pp. 280-285, February 2005. 30, no. 12, pp. 873-888, 2004. [P62] M. Jørgensen and D. Sjøberg, “The importance of not learning [P45] M. G. Pitts and G. J. Browne, “Improving requirements elicita- from experience”. In Proceedings of Conference on European Soft- tion: An empirical investigation of procedural prompts”. Infor- ware Process Improvement. pp. 2-2, 2000. mation Systems Journal, vol. 17, no. 1, pp. 89-110, 2007. [P63] K. Moløkken and M. Jørgensen, “Software effort estimation: Un- [P46] G. Calikli, B. Aslan, and A. Bener, “Confirmation bias in soft- structured group discussion as a method to reduce individual ware development and testing: An analysis of the effects of biases”. In Proceedings of the 15th Annual Workshop of the Psychol- company size, experience and reasoning skills”, In Proceedings ogy of Programming Interest Group (PPIG 2003), pp. 285-296, 2003. of 22nd Annual Psychology of Programming Interest Group Work- [P64] K. Molokken-Ostvold and Haugen, “Combining estimates with shop, 2010. planning poker-an empirical study”, In Proceedings of 18th Aus- [P47] C. Mair and M. Shepperd, “Human judgement and software tralian Software Engineering Conference (ASWEC 2007). pp. 349- metrics: vision for the future”. In Proceedings of the 2nd interna- 358, 2007. tional workshop on emerging trends in software metrics, pp. 81-84, [P65] J. A. O. G. da Cunha and H. P. de Moura, “Towards a substan- May 2011. tive theory of project decisions in software development pro- [P48] M. Jørgensen, “Identification of more risks can lead to increased ject-based organizations: A cross-case analysis of IT organiza- over-optimism of and over-confidence in software develop- tions from Brazil and Portugal”. In Proceedings of 10th Iberian ment effort estimates”. Information and Software Technology, vol. Conference on Information Systems and Technologies (CISTI), pp. 1- 52, no. 5, pp. 506-516, 2010. 6), 2015. [P49] M. Jørgensen and T. Halkjelsvik, “The effects of request formats [P66] H. van Vliet and A. Tang, “Decision making in software archi- on judgment-based effort estimation”, Journal of Systems and tecture”. Journal of Systems and Software, vol. 117, pp. 638-644, Software, vol. 83, no. 1, pp. 29-36, 2010. 2016. [P50] M. Jørgensen, K. H. Teigen, and K. MoløKken, “Better sure than [P67] J. A. O. da Cunha, F. Q. da Silva, H. P. de Moura, and F. J. safe? Over-confidence in judgement based software develop- Vasconcellos, “Decision-making in software project manage- ment effort prediction intervals”, Journal of Systems and Software, ment: a qualitative case study of a private organization”. In Pro- vol. 70, no. 1, pp. 79-93, 2004. ceedings of the 9th International Workshop on Cooperative and Hu- [P51] M. Jørgensen, “Individual differences in how much people are man Aspects of Software Engineering, pp. 26-32, May 2016. affected by irrelevant and misleading information”, In Second European Conference on Cognitive Science, Delphi, Greece, Hellenic

Cognitive Science Society, 2007. [P52] K. Moløkken and M. Jørgensen, “Expert estimation of web-de- velopment projects: are software professionals in technical roles more optimistic than those in non-technical roles?”. Empirical

Software Engineering, vol. 10, no. 1, pp. 7-30, 2005. [P53] T. K. Abdel-Hamid, K. Sengupta, and D. Ronan, “Software pro- ject control: An experimental investigation of judgment with fallible information”. IEEE Transactions on Software Engineering, vol. 19, no. 6, pp. 603-612, 1993. [P54] T. Connolly and D. Dean, “Decomposed versus holistic esti-

mates of effort required for software writing tasks”, Manage-

ment Science, vol. 43, no. 7, pp. 1029-1045, 1997.

[P55] M. Jørgensen, D. I. Sjøberg, “Software process improvement and