Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle

Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner. This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006--2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. This paper documents the above study and explores reasons for this mismatch between this common rule of thumb and empirical data. In summary, DIE is not some constant across all projects. Rather, DIE might be an historical relic that occurs intermittently only in certain kinds of projects. This is a significant result since it predicts that new development processes that promise to faster retire more issues will not have a guaranteed return on investment (depending on the context where applied), and that a long-held truth in software engineering should not be considered a global truism.Comment: 31 pages. Accepted with minor revisions to Journal of Empirical Software Engineering. Keywords: software economics, phase delay, cost to fi

Fluid Tasks and Fluid Teams: The Impact of Diversity in Experience and Team Familiarity on Team Performance

In this paper, we consider how the structures of tasks and teams interact to affect team performance. We study the effects of diversity in experience on a team's ability to respond to task changes, by separately examining interpersonal team diversity (i.e., differences in experience across the entire team) and intrapersonal team diversity (i.e., whether individuals on the team are more or less specialized). We also examine whether team familiarity - team members' prior experience working with one another - helps teams to better manage challenges created by task changes and greater interpersonal team diversity. Using detailed project- and individual-level data from an Indian software services firm, we find that the interaction of task-change with intrapersonal diversity is related to improved project performance, while the interaction of task-change with interpersonal diversity is related to diminished performance. Additionally, the interaction of team familiarity with interpersonal diversity is related to improved project performance in some cases. Our results highlight a need for more nuanced approaches to leveraging experience in team management.Diversity, Knowledge Work, Project Flexibility, Task Change, Team Familiarity

The Challenge of Improving Software Quality: Developers\u27 Beliefs about the Contribution of Agile Practices

We observe that systems developers who have had experience with agile development projects often express their opinion that agile methodologies are superior to plan-driven methodologies. In order to collect empirical evidence to support or discount this belief, we conducted a survey among software developers about software quality and development practices. Our study identified eight quality goals from the software quality literature. We then asked the participants to identify which of eight practices contributes the most towards that quality goal. Half of the practices were agile practices; half were plandriven practices. We found that, for each and every quality goal, the participants as a whole chose one of the agile practices as a best practice enabling them to reach each quality goal. While this study does not conclude that agile methods are always the best approach, it does reveal that agile practices are being noticed and appreciated by many system developers

The Influence of Personality on Code Reuse

The ubiquity and necessity of computer software requires programmers to reuse extant code to keep up with increasing software demands. Researchers have started to investigate the underlying psychological processes and the programmer characteristics affecting code reuse. The present study investigated the role of programmer personality (propensity to trust, suspicion propensity) on willingness to reuse code. Programmers were recruited through Amazon’s Mechanical Turk. Programmers completed propensity to trust and suspicion personality inventories and were subsequently presented with 18 pieces of computer code containing transparency and reputation manipulations. The results demonstrated that propensity to trust did not influence willingness to reuse code. However, facets of suspicion propensity did affect reuse willingness. Programmers lower in trait mal-intent perceptions and higher in cognitive activity were more likely to report they would reuse code. Implications and applications are discussed

A research review of quality assessment for software

Measures were recommended to assess the quality of software submitted to the AdaNet program. The quality factors that are important to software reuse are explored and methods of evaluating those factors are discussed. Quality factors important to software reuse are: correctness, reliability, verifiability, understandability, modifiability, and certifiability. Certifiability is included because the documentation of many factors about a software component such as its efficiency, portability, and development history, constitute a class for factors important to some users, not important at all to other, and impossible for AdaNet to distinguish between a priori. The quality factors may be assessed in different ways. There are a few quantitative measures which have been shown to indicate software quality. However, it is believed that there exists many factors that indicate quality and have not been empirically validated due to their subjective nature. These subjective factors are characterized by the way in which they support the software engineering principles of abstraction, information hiding, modularity, localization, confirmability, uniformity, and completeness

Assessing Practitioner Beliefs about Software Defect Prediction

Just because software developers say they believe in "X", that does not necessarily mean that "X" is true. As shown here, there exist numerous beliefs listed in the recent Software Engineering literature which are only supported by small portions of the available data. Hence we ask what is the source of this disconnect between beliefs and evidence?. To answer this question we look for evidence for ten beliefs within 300,000+ changes seen in dozens of open-source projects. Some of those beliefs had strong support across all the projects; specifically, "A commit that involves more added and removed lines is more bug-prone" and "Files with fewer lines contributed by their owners (who contribute most changes) are bug-prone". Most of the widely-held beliefs studied are only sporadically supported in the data; i.e. large effects can appear in project data and then disappear in subsequent releases. Such sporadic support explains why developers believe things that were relevant to their prior work, but not necessarily their current work. Our conclusion will be that we need to change the nature of the debate with Software Engineering. Specifically, while it is important to report the effects that hold right now, it is also important to report on what effects change over time.Comment: 9 pages, 3 Figures, 4 Tables, ICSE SEIP 202

Cross-layer system reliability assessment framework for hardware faults

System reliability estimation during early design phases facilitates informed decisions for the integration of effective protection mechanisms against different classes of hardware faults. When not all system abstraction layers (technology, circuit, microarchitecture, software) are factored in such an estimation model, the delivered reliability reports must be excessively pessimistic and thus lead to unacceptably expensive, over-designed systems. We propose a scalable, cross-layer methodology and supporting suite of tools for accurate but fast estimations of computing systems reliability. The backbone of the methodology is a component-based Bayesian model, which effectively calculates system reliability based on the masking probabilities of individual hardware and software components considering their complex interactions. Our detailed experimental evaluation for different technologies, microarchitectures, and benchmarks demonstrates that the proposed model delivers very accurate reliability estimations (FIT rates) compared to statistically significant but slow fault injection campaigns at the microarchitecture level.Peer ReviewedPostprint (author's final draft

Omission of quality software development practices : a systematic literature review

Software deficiencies are minimized by utilizing recommended software development and quality assurance practices. However, these recommended practices (i.e., quality practices) become ineffective if software professionals purposefully ignore them. Conducting a systematic literature review (n = 4,838), we discovered that only a small number of previous studies, within software engineering and information systems literature, have investigated the omission of quality practices. These studies explain the omission of quality practices mainly as a result of organizational decisions and trade-offs made under resource constraints or market pressure. However, our study indicates that different aspects of this phenomenon deserve further research. In particular, future research must investigate the conditions triggering the omission of quality practices and the processes through which this phenomenon occurs. Especially, since software development is a human-centric phenomenon, the psychological and behavioral aspects of this process deserve in-depth empirical investigation. In addition, futures research must clarify the social, organizational, and economical consequences of ignoring quality practices. Gaining in-depth theoretically sound and empirically grounded understandings about different aspects of this phenomenon enables research and practice to suggest interventions to overcome this issue.fi=vertaisarvioitu|en=peerReviewed