We Don't Need Another Hero? The Impact of "Heroes" on Software Development

A software project has "Hero Developers" when 80% of contributions are delivered by 20% of the developers. Are such heroes a good idea? Are too many heroes bad for software quality? Is it better to have more/less heroes for different kinds of projects? To answer these questions, we studied 661 open source projects from Public open source software (OSS) Github and 171 projects from an Enterprise Github. We find that hero projects are very common. In fact, as projects grow in size, nearly all project become hero projects. These findings motivated us to look more closely at the effects of heroes on software development. Analysis shows that the frequency to close issues and bugs are not significantly affected by the presence of project type (Public or Enterprise). Similarly, the time needed to resolve an issue/bug/enhancement is not affected by heroes or project type. This is a surprising result since, before looking at the data, we expected that increasing heroes on a project will slow down howfast that project reacts to change. However, we do find a statistically significant association between heroes, project types, and enhancement resolution rates. Heroes do not affect enhancement resolution rates in Public projects. However, in Enterprise projects, the more heroes increase the rate at which project complete enhancements. In summary, our empirical results call for a revision of a long-held truism in software engineering. Software heroes are far more common and valuable than suggested by the literature, particularly for medium to large Enterprise developments. Organizations should reflect on better ways to find and retain more of these heroesComment: 8 pages + 1 references, Accepted to International conference on Software Engineering - Software Engineering in Practice, 201

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

Die Betrachtung der Earned Value Methodik im agilen Projektumfeld hinsichtlich des Projekterfolgs

The Earned Value analysis has proven to be beneficial in waterfall and located software projects for monitoring the project management triangle. Nowadays, more and more virtual and agile project teams are used to manage the software requirements process. However, it remains unclear whether using the Earned Value metrics’ general positive effect generates project success in such an area too as additional challenges arise like communication or coordination difficulties. This thesis examines the assumption of a positive influence of the Earned Value technique on the project success during the software requirements process within a virtual, global project team in an agile software project environment. In addition, it should be clarified whether coordination and communication elements moderate this effect. The research is achieved with a sample size of 190,051 international people, mainly extracted from the consulting company Capgemini. Therefore, a mixed methods approach is used which consists of a partially-standardized and structured online survey as well as non-standardized and semi-structured guided interviews. The analyses of the latter ones are based on Mayring’s content analysis. This dissertation has not revealed any evidence of a positive influence on the project success by the Earned Value analysis during the requirements process in virtual project teams of an agile software project. This outcome is based on an inconsistent view of how to successfully apply this project controlling approach, whereby the subjective perception of project success played an important role. In this particular context, the Earned Value metrics reached their practical limits due to certain challenges named within this research. Although, the moderation analysis showed no significant effects of communication or coordination on the relation between the Earned Value method and the project success during the requirements process in a virtual agile software project team, a positive tendency emerged from both dimensions. The thesis presents some prerequisites that must be fulfilled in order to weaken or even reduce the problems in the application of the Earned Value analysis in this research context. Lastly, consistent definitions as well as standardized utilization understandings are required for a successful implementation of the Earned Value controlling instrument in this particular field

Distributed Development Considered Harmful?

Abstract—We offer a case study illustrating three rules for reporting research to industrial practitioners. Firstly, report “relevant ” results; e.g. this paper explores the effects of distributed development on software products. Second: “recheck ” old results if new results call them into question. Many papers say distributed development can be harmful to software quality. Previous work by Bird et al. allayed that concern but a recent paper by Posnett et al. suggests that the Bird result was biased by the kinds of files it explored. Hence, this paper rechecks that result and finds significant differences in Microsoft products (Office 2010) between software built by distributed or collocated teams. At first glance, this recheck calls into question the widespread practice of distributed development. Our third rule is to “reflect ” on results to avoid confusing practitioners with an arcane mathematical analysis. For example, on reflection, we found that the effect size of the differences seen in the collocated and distributed software was so small that it need not concern industrial practitioners. Our conclusion is that at least for Microsoft products, distributed development is not considered harmful. I