We don’t need another hero? The impact of “heroes” in software development

Hero developers are often thought to be bad for software projects, due to their tendency to write code on their own without collaborating with team members. This paper by Agrawal, Rahman, Krishna, Sobran, and Menzies attemps to debunk that myth, but also leaves the most important question unanswered.

Hero developers are very productive and get things done quickly. This is generally a good thing, especially when deadlines are tight.

But every silver lining has a cloud: hero developers quickly become irreplaceable and form bottlenecks in the development process, as they might not feel the need to collaborate and share knowledge (side note: Even if it’s just comments within the code) with team members. It is believed that this is harmful for projects, as it would negatively impact the quality of the produced software.

The authors selected 661 open source and 171 commercial longer-running software projects on GitHub that are under active development by at least 8 different contributors.

Each project was classified as a “hero” or “non-hero” project, depending on whether 20% of the developers made more than 80% of the commits (side note: This implies that the term “hero” possibly includes stereotypical “cowboys” as well as technical leads, benevolent dictators for life (BDFLs), and normal developers that simply haven’t switched projects very often.

The paper becomes a lot less exciting once you realise that.).

Finally, the ratio of resolved issues and the speed at which those issues were resolved were calculated for both groups in order to determine how the presence of hero developers affects those metrics.

The results suggest that overall, a whopping four out of five software projects can be classified as hero projects. Moreover, as projects grow larger they are more likely to become hero projects.

The presence of hero developers does not affect how many or how quickly bug issues and change requests are resolved. It does affect the ratio of resolved enhancement issues, which is significantly higher for commercial projects and lower for open source projects.

The authors therefore conclude that heroes have a positive impact on software quality, and argue that organisations should find and retain more of these heroes.

I don’t completely agree with that conclusion.

The chosen metrics are not good indicators of software quality: for instance, if a project has large numbers of small bugs that are quickly fixed, this would be mistakenly interpreted as “high quality”.

The authors also appear to have overlooked the impact of hero developers on project continuity if a hero ever decides to leave for a different project. This is a much bigger threat from a business perspective, and one that will overshadow any benefits one might gain from having slightly more enhancements.