ACM

Communications of the ACM

Home/Magazine Archive/September 2008 (Vol. 51, No. 9)/Using Traceability to Mitigate Cognitive Biases in.../Full Text

Virtual extension

Using Traceability to Mitigate Cognitive Biases in Software Development

By Kannan Mohan, Radhika Jain
Communications of the ACM, September 2008, Vol. 51 No. 9, Pages 110-114
10.1145/1378727.1389970
Comments

View as: Print Mobile App ACM Digital Library Full Text (PDF) Share:

Are Software Developers Affected by Cognitive biases while performing changes to design artifacts? If so, how can we mitigate the impact of such biases on developers' performance? Despite the criticality of these questions, they have been relatively unexplored in the context of software development. When making changes to software artifacts, developers use heuristics that are influenced by cognitive biases. The goal of this article is to examine this influence and to explore whether such biases can be mitigated by using cognitive aids such as traceability (See accompanying sidebar). This article describes the findings of our study and provides recommendations for practice.

Cognitive Biases in Problem-Solving

People employ cognitive biases to reduce uncertainty and complexity when processing information during problem solving.¹¹ While the effects of these biases have been well studied in general problem-solving, their impact on software development has gained limited attention. These biases are often employed to simplify complex inference tasks to more manageable proportions.⁸ The most common cognitive biases experienced during problem-solving include anchoring and adjustment, availability, and confirmation.

Anchoring and Adjustment Bias

This bias results from people forming initial estimates about a problem and adjusting their initial estimates to arrive at more appropriate final solutions.^8,10 This initial estimate is called as an anchor - 'a familiar/known position or a reference point', that is subject to adjustments.^5,7 Typically, these adjustments are insufficient.¹¹ Anchoring and adjustment have been known to impact tasks like artifact reuse and decision making.⁸ Anchors can be self-generated or externally-generated. To form self-generated anchors, developers retrieve their long-held beliefs (say, past development and domain experiences) from their memory to draw inferences about a task. This is similar to the concept of conservatism. Conservatism is defined based on the following three aspects:

The tendency of people to overlook information that is inconsistent with their long-held beliefs.⁴ People fail to revise their previous decisions, findings, or interpretations in light of new information and hold onto their longer-term opinions,¹
The time interval between the initial estimate and the judgment task is long,⁷ and a In our study, individuals did not tend to overlook information that was inconsistent with self-generated anchors, rather they adjusted these self-generated anchors. These self-generated anchors can also be disrupted or changed by intervening variables.
Influence of this tendency on judgments over a longer period of time without being disrupted by intervening values.^4,6

Self-generated anchors exhibit only the second characteristic of conservatism (the long time interval). The other two aspects of conservatism are not necessarily manifested by self-generated anchors.^a This discussion implies that conservatism and anchoring are analogous but distinct concepts.

Externally-generated anchors, on the other hand, are triggered by certain artifacts such as system documentation, requirements specification, etc. used by developers. Developers may combine self- and externally-generated anchors or use externally-generated anchors to adjust self-generated anchors to arrive at acceptable solutions. Irrespective of the source, these anchors may be inaccurate and developers may be unaware of these inaccuracies and thereby not realize the need for adjustment. Specific mechanisms are needed to make developers aware of the same. Insufficient adjustments are made when there is an uncertainty about the correct solution. This may lead to premature termination of the task due to reluctance to spend more effort to adjust sufficiently or due to lack of appropriate cognitive resources to facilitate the process of adjustment.

Availability bias

This bias suggests that people are influenced by information that is easier to recall and are prejudiced by information that is well-publicized or recent.¹⁰ This suggests that in the absence of any usable knowledge about a system, developers may draw heavily upon their conveniently accessible past experiences. Such experiences may not always be consistent with the current system state and might have undesirable consequences. For example, it might result in erroneous changes to the system if their experiential beliefs are inconsistent with current system state.

Confirmation bias

This bias suggests that people tend to focus on information that is consistent with their preconceived notions while they disregard information that is inconsistent with their past conceptualizations.³ In other words, people mostly seek evidence that qualifies their beliefs rather than evidence that disqualifies them.¹ Developers' past beliefs might dictate the importance placed on new information about requirements, design, and solution.

Since the evidence of the impact of these biases in software development is largely anecdotal, we empirically investigated this phenomenon and the role of traceability in shaping these biases.

How Do Cognitive Biases Affect Software Development?

Findings from our study (see accompanying sidebar) demonstrate the presence of cognitive biases in software development. Anchoring and adjustment was found to occur at various stages during the process of making changes to system design. Developers alternated between anchoring and adjustment for different purposes (for example, to develop an initial understanding of requirements, system design, and task). Confirmation and availability biases were found to affect the process of anchoring and adjustment through the nature of knowledge available to and sought by the developers.

Forming Anchors

During each step in the process of handling a change, developers anchored to their initial understanding of the requirement (requirement anchor), current design artifacts (design anchor), and the solution for the change requested (solution anchor). For example, after developers read new requirement specification, they developed an initial understanding (requirement anchor) about the requirement even before actually examining system documentation to understand it in the context of the system. This is typically a combination of self and externally-generated anchors: self-generated from their preconceived notions about the domain and externally-generated by the implied semantics in new requirement specification.^{2 b}

Impact of Traceability

Based on the verbal protocol analysis, we found that developers in the pure control group typically formed anchors that were different and often less accurate when compared to those in the treatment group. Let us consider one of the four maintenance tasks performed by the pure control group: "incorporation of reservation functionality in the library management system." They formed an initial anchor that 'reservation functionality' is same as 'hold functionality' (requirement anchor). This was primarily triggered due to the disuse of traceabil-ity knowledge that could have helped them make the distinction between their belief and the actual functionality. Their interpretation was based solely on their level of familiarity and their mental model of library domain. They had no mechanisms to confirm or disconfirm their beliefs leading them to confide in their incomplete and inconsistent knowledge. They anchored to these estimates and made ill-informed changes that were inaccurate, incomplete, and inconsistent with the current system state. Although subjects in the control and pure control groups did not arrive at incorrect interpretations in every instance (say, when developers needed to understand design of the existing system and the impact of changes), they did so in most instances.

Developers in the treatment group formed more appropriate understanding of current design artifacts (design anchor) and the impact of the changes (solution anchor) more often than the control and pure control groups. For example, they used traceability knowledge to identify the impact of the introduction of the new functionality. Most often, they were also able to correctly identify alternatives available in current design that can be leveraged in implementing the new requirement as a result of the links provided by the traceability knowledge from related requirements to such alternatives. Developers in the control and pure control groups were usually unable to completely identify the impact of the 'reservation functionality' and made decisions based on their initial anchor of what needs to be changed. This observation of differences based on developers' verbal protocols was consistent in most of the instances when subjects needed to understand existing system and the impact of changes. This behavior of developers corroborates the existence of availability and confirmation biases when anchoring to estimates of a solution and the role of traceability in mitigating the effect of these biases.

Adjusting Anchors

Developers iteratively adjusted their anchors as they navigated through various design artifacts. After examining a few design artifacts and without expending significant cognitive effort in understanding what might be relevant to the change request, developers initially formed anchors about the current system state. However, developers did not always adhere to these anchors. As they discovered new information from the design artifacts and available system documentation, they adjusted their anchors to come closer to acceptable solutions.

Impact of Traceability

Developers in the pure control group demonstrated relatively less appropriate adjustments compared to the treatment group. For example, developers in the treatment group who were anchored to the understanding that reservation is same as hold functionality adjusted this initial anchor after studying traceability knowledge, which revealed that hold functionality was already available. This led them to examine the change request and traceability knowledge thoroughly to understand the requirement accurately (adjusting flawed requirement anchor). Thus, despite their inappropriate initial anchors, these developers later adjusted to better reflect appropriate understanding of the task. This adjustment process was cumbersome for those who did not examine available trace-ability knowledge at all or used it as a last remedy. In most instances, developers in the pure control groups typically did not realize that their solutions were ineffective and incomplete, giving them a false sense of completion.

The extent of adjustment was primarily determined by the nature of traceability knowledge developers utilized in performing these tasks. Developers in the treatment group were able to adjust their anchors in most instances to more accurately reflect the current system state when compared to developers in the control and pure control groups. For example, for the reservation functionality, the high-end traceability model documents locations in the design that can accommodate the changes required whereas low-end practices simply provide links between the requirement for existing hold functionality and the design elements that implement this functionality. Specificity and the amount of knowledge provided by high-end traceability practices enabled developers to reach a more accurate solution as they were able to identify existing locations in design that can facilitate needed changes and leverage them in implementing the new functionality. Due to the effort required to study this information, some developers were reluctant to examine it until it became absolutely essential that they were unable to perform the task without consulting the traceability knowledge. But when they did use it, they usually realized that their anchors were not good enough and adjusted to arrive at more accurate anchors.

Summary of findings

Evidence from our study demonstrates: 1. Both the presence and the interplay among anchoring and adjustment, availability, and confirmation biases in software development. 2. That traceability knowledge reduces the adverse effect of these biases on complex maintenance tasks. This was not the case for simple tasks where understanding the traceability knowledge demanded more cognitive effort than required by the task. Thus, for complex tasks, though considerable time is spent in understanding existing traceability knowledge, this results in higher quality changes when compared to quick-fix changes made without such knowledge.

Based on the findings from our study, we propose a causal framework that depicts the relationship between traceability, task complexity, cognitive biases, and maintenance performance (Figure 1). This model suggests that an improvement in traceability practices improves performance through the mitigation of cognitive biases and that this improvement is higher for complex tasks.

Mitigating Cognitive Biases

Drawing from our study, we suggest the following strategies to mitigate adverse effect of cognitive biases:

Provide tailored traceability: In our study, high-end traceability users adjusted most appropriately, producing highest quality changes. This suggests that development of high-end trace-ability models tailored to project-specific needs (say, product family development, agile development, etc.) becomes essential in mitigating cognitive biases. This reiterates the need to develop project-specific traceability environments.²
Establish tight integration between design artifacts and traceability knowledge: One reason why developers are inhibited from using documentation is the weak connection between design artifacts and the traceability knowledge. Although traceability knowledge provided to the subjects in our study had significantly closer relationship to design artifacts than what is typical in the industry, it was apparent that tighter integration would have been much more valuable. If developers can navigate seamlessly between traceability knowledge and the artifacts that need changes, effort exerted for navigation will be lower, making traceability knowledge more accessible and available. This will help developers better comprehend the impact of their changes, thereby instigating them to adjust sufficiently.
Provide visually supported traceability knowledge: It is essential to provide appropriate visual aids to depict impact of changes. Developers spent a major portion of time in finding answers to questions of descriptive nature (what needs to be changed and where artifacts to be changed are located) and of evaluative nature (evaluating the completeness and accuracy of tasks). By providing visually supported traceability knowledge, time expended to study traceability knowledge can be minimized.
Motivate developers to use trace-ability knowledge: Typically, developers consider sifting through traceability knowledge as wastage of valuable time that could be spent in actually performing the modifications. However when handling complex maintenance tasks without traceability, developers spend significant amount of time in futile attempts to solve the problem only to later realize the usefulness of trace-ability in helping them identify the relevant artifacts to be changed. System quality is adversely affected by such ill-informed changes. This could result in further effort spent in future in refactoring the system. Traceability tool developers should develop environments that will induce developers to navigate through traceability knowledge before performing changes.

Conclusions

Software development organizations need to recognize the importance of the impact of developers' cognitive biases on the software development and maintenance process and take adequate measures to address them to improve performance. In this study, we have demonstrated traceability as an effective solution to address cognitive biases. This is one of the first studies that provides a theoretical motivation for the acquisition and use of traceability knowledge. The key implications drawn from this study highlight the need to establish and motivate developers to use tailored traceability practices. Future research should investigate appropriate incentive structures to motivate developers to follow such traceability practices.

References

1. Arnott, D. Cognitive biases and decision support systems development: a design science approach. Information Systems Journal, 16 (1), 2006, 5578

2. Domges, R. and Pohl, K. Adapting Traceability Environments to Project-Specific Needs. Communications of the ACM, 41 (12), 1998, 5462.

3. Fisher, K. and Statman, M. Cognitive Biases in Market Forecasts: The frailty of forecasting. The Journal of Portfolio Management, 2000,110.

4. Harvey, N. and Harries, C. Effects of judges forecasting on their later combination of forecasts for the same outcomes. International Journal of Forecasting, 20 (3), 2004, 391409.

5. Kahneman, D. and Tversky, A. On the psychology of prediction. Psychology Review, 80,1973, 237251.

6. Kirs, P.J., Pflughoeft, K. and Kroeck, G. A process model cognitive biasing effects in information systems development and usage. Information & Management, 38 (3), 2001,153165.

7. Kydd, C.T Cognitive biases in the use of computer-based decision support systems. Omega, 17 (4), 1989 335344.

8. Parsons, J. and Saunders, C. Cognitive Heuristics in Software Engineering: Applying and Extending Anchoring and Adjustment to Artifact Reuse. IEEE Transactions On Software Engineering, 30 (12), 2004. 873888.

9. Ramesh, B. and Jarke, M. Towards Reference Models for Requirements Traceability. IEEE Transactions on Software Engineering, 27 (1), 2001, 5893.

10. Stacy, W. and MacMillan, J. Cognitive bias in software engineering. Communications of the ACM, 38 (6) 1995, 5763.

11. Tversky, A. and Kahneman, D. Judgment under Uncertainty: Heuristics and Biases. Science, 185 (4157), 1974, 11241131.

Authors

Kannan Mohan ([email protected]) is an Assistant Professor of Computer Information Systems at the Zicklin School of Business, Baruch College, City University of New York (CUNY) - New York, NY.

Radhika Jain ([email protected]) is an Assistant Professor of Computer Information Systems at the Zicklin School of Business, Baruch College, City University of New York (CUNY) - New York, NY.

Footnotes

a. In our study, individuals did not tend to overlook information that was inconsistent with self-generated anchors, rather they adjusted these self-generated anchors. These self-generated anchors can also be disrupted or changed by intervening variables.

b. It should be noted that this is different from conservatism in that developers do not tend to hold onto these initial beliefs in light of new information

DOI: http://doi.acm.org/10.1145/1364782.1389970

Figures

Figure 1. Proposed Causal Framework

Tables

Table 1. Experimental Design

Table 2. Summary of findings

Sidebar: Traceability

Traceability is defined as the ability to describe and follow the life of any conceptual or physical software artifact throughout the various phases of software development, linking requirements to design artifacts. When changes are performed to the system, traceability can be used to identify their impact. Traceability between requirements and their implementation can help clarify possible mismatches in developers' understanding of the system and the actual system state. Organizations typically follow two types of requirements traceability practices: pre-and post-traceability. While pre-traceability focuses on examining the source of a requirement back to its origin, post-traceability focuses on the refinement, deployment, and use of a requirement in the development life cycle. Here, we primarily focus on post-traceability.

Traceability practices also range from low-end to high-end;⁹ Low-end practices focus on linking common software artifacts like requirements, design elements, and source code using simple traceability matrices. Low-end practices are typically used as a one-size-fits-all solution. High-end traceability practices use customized traceability models and specialized tools with customer satisfaction and system quality as objectives. In addition to artifacts documented by low-end practices, high-end practices also document significant amount of process knowledge like rationale, decisions, issues, alternatives, etc. Based on the type of project, different traceability models (semantic networks of knowledge elements and meaningful links among them) are developed and used. Such models focus on knowledge elements that are most valuable in specific situations. Elements and links in the network change depending on project characteristics.

Sidebar: How the Study was Conducted

Ten developers (average experience of four years) were asked to perform changes to the design of an existing system. Developers had experience in various problem domains like financial information systems, warehouse management systems, labor management systems, etc. None of them had experience in library management. We provided them with UML design models and documentation of a library management system. Traceability knowledge is used as a manipulation to examine how it affects cognitive biases. Table 2 shows the experimental design.

Subjects were asked to perform four maintenance tasks (two tasks were simple training tasks to get them used to think aloud) at two different levels of complexity. Subjects were asked to verbalize their thoughts as they performed the tasks. Time taken by subjects to complete the tasks ranged from about one to two hours. All tasks involved performing changes at design level and not at the detailed source code level. Their verbal protocols were recorded, transcribed, and analyzed. Data analysis was done using open, axial, and selective coding techniques commonly used as part of grounded theory method.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.