11 ms·

Software Projects and Heroes: Lessons Learned from GitHub Projects

337 points by gmolau 7y ago

jeandejean 7y ago
Very interesting. But that probably doesn't translate to professional projects where people have more incentive to contribute and core contributors the obligation to onboard and mentor new hires...
- convolvatron 7y ago
  indeed. i dont think its wise to dismiss the corporate aversion to 'heroes'. while its certainly possible to make an outsized contribution without getting burned out or devaluing other contributors, thats often not what happens.
  - nitrogen 7y ago
    devaluing other contributors Maybe this isn't what you meant, but why is it that human beings see someone they know producing a lot of value as diminishing the value produced by others, especially in technical matters?
    - wolco 7y ago
      Because people compare and if someone is doing a lot morr than everyone else it makes everyone look bad. Why? Because the mba will see a metric elevated and use that to define a norm. Now they only want to hire 10x performers. They don't know how to find them so they invent this complex hiring process that filters out so many good candidates they have no chance of ever finding that 10x developer. They settle on the fake 10x who speaks well and presents all of the right signals. The dev comes in and struggles and blames the code/past developer/way something is done and claims a rewrite is needed in a new and trendy language. This prompts a huge rewrite that takes place over a year at the end of which its determined that nothing works and that project gets cancelled. By this point that developer has been promoted to your manager.
  - diminoten 7y ago
    Isn't this paper saying exactly the opposite, though? That it does happen, and quite often?
- falcongod082 7y ago
  If you think that "why" someone contributes is meaningful, I'm curious how you think that professional projects (whatever that means) and whatever arbitrary metric is being used to encourage incentive would give a different result.
  - jrumbut 7y ago
    For instance, on a minuscule open source project of mine, I wrote all the code and another developer has (kindly) stepped up and managed upgrades to one of the dependencies, bumping the version number when it's time to do so. If he and I were employed together to work on this project, a workload distribution of me writing and maintaining the entire codebase (minus one line) and him coming by every couple months to update a version number would not be a very fair or realistic division of labor. The open source development process is very different from anything else. None of my projects at work have a long tail of contributors submitting comment typo fixes.
    - diminoten 7y ago
      It'd be much more fair if the project at your job started out as a proof-of-concept that you wrote, while the other dev worked on other things. Once your proof-of-concept grew into something management wanted, you'd probably still be writing a lot of the code, and the other developer would be contributing, but in the realm of 20% of the codebase, at least to start (and according to this article, that wouldn't change).
      - jrumbut 7y ago
        You're right, and I don't doubt the value of studying open source projects or that it's the best that can be done given the data available, but there are limitations on how much light this data can shed on the great mass of code being written within organizations. Maybe the results do apply to the situation you describe, I'd be curious to know that.
  - jeandejean 7y ago
    I'd say two things, the first is that if you're not paid, you don't have that much incentive to contribute hardly so it's no surprise that most OS projects are maintained by a handful of (great indeed) highly motivated developers. Second is that it's something widely known that developers are not flexible, so if they're in charge of their baby, they won't make so many efforts to encourage outsiders contributions. Whereas in a corp environment, managers and other devs should make sure it doesn't become an obstacle to contributions. That's not very precise but I think people can relate to what I said.
- jcriddle4 7y ago
  "...In 2018, Agrawal...studied...661 open source and 171 in-house proprietary projects. In that sample, over 89% of all projects were hero-based..." In theory a "professional" project would want efficiency so all developers contributing fairly equally however the data does not support that. Wide variances in developer productivity are widely documented. I would think open source projects also have to work to onboard and mentor new developers or they would eventually die out. You might say that professional projects are possibly larger but the study indicated size didn't matter "...the bug injection distributions of heroes and nonheroes is barely changed after stratifying the data according to project size. Hence, when discussing the external validity of these conclusions, we need not explore issues of team size and hero prevalence." I don't see any data that suggests this study would not generalize to professional projects.
deleted 7y ago
[deleted]
kartan 7y ago
> A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers. If that 20% leave, the other 80% would contribute equally or the ration 20/80 will be preserved? This seams a feedback loop. Once a developer has written more code than others is in a better position to write even more. If that is the case "hero developer" is a floating position, depending so much on your skill and how much time you have been working in a project and other circumstances. > Organizationsshould reflect on better ways to find and retain more ofthese software heroes. I had this discussion recently. If you create a team of "heroes" all become way slower than when they were in different teams. My personal conclusion, and the way of working that I try to implement at work is that small independent projects allow for developers to be fast and reliable. If your project is correctly divided, anyone can contribute ( at their level of expertise). If you have a big complex projects then old-timers that created originally the code are the only ones that can work with it efficiently if no other developers make big changes (reducing the ability of other developers to contribute independently of their level of skill). So, before going in search of "heroes" think if your projects are correctly divided. And think about the risk that you create when a "hero developer" is needed and leaves.
- svaha1728 7y ago
  I recently left a company organized in this way. It was quite disheartening: small changes would break the code in multiple ways, hundreds of public functions, no interfaces. The architect was seen as a ‘super’ developer...
  - timClicks 7y ago
    Perhaps an ideal scenario would be to have a single 'super' developer have relatively free reign, under the condition that she can explain the code/architecture to others effectively also.
    - duncan-donuts 7y ago
      Yeah, definitely not an ideal scenario.
cookiecaper 7y ago
> A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers. Where does this definition come from? It sounds quite typical to me. Even in large projects like the Linux kernel, if you break them down into comprehensible units and subsystems, I would expect you'd find essentially the same thing. The vast majority of projects likely meet the "hero project" threshold defined above, whether they're good or bad. I don't know of any movement to specifically prevent having primary contributors; the main interest from the corporate world is ensuring that primary contributors can be cycled as necessary. This doesn't seem like news in any way. I don't want to be unduly dismissive as I haven't read the paper, but I think I'm catching a distinctive whiff of "publish or perish" in the vicinity...
xrd 7y ago
This is really fascinating. If true, it suggests that big companies with huge teams that try to force the entire team into equal contribution metrics are creating stress that might not help the team, nor lead to fewer bugs (big surprise). I've never been on a team which was set up to truly recognize the value different forms of contribution, like writing tests, or removing code, or simplifying it, or other things which would not count towards the hero metric presented here. As an industry we just don't think about alternative narratives to "let's make sure everyone is an equal contributor..."
- revvx 7y ago
  Code Reviews are also devalued, to the point of most developers I worked with considering it a chore.
  - xrd 7y ago
    That's a great point. The cost of doing that is never calculated and the impact is so positive.
- asimpletune 7y ago
  Yeah that’s a very interesting observation, and sort of corroborates my own anecdata. More specifically, when projects are in there infancy, and there’s a lot of risk associated with working on them, I feel that management tends to stay away, which is how these heroes originate. Then, after it’s obvious that project will succeed and it’s merits are overwhelming, you see this shift in project governance/responsibility towards a more corporate mode. However, like you said, that’s probably counter productive and just creates stress and tension. If anything, I think sometimes management has an uncontrollable tendency to position itself strategically in these gatekeeper roles, whereas in open source they don’t get to do that simply by virtue of being someone’s boss, so you don’t see that same trend, as the paper argues. Not sure if that makes sense, I quickly typed this on my phone.
  - Data_Junkie 7y ago
    That is the untalented who are interested in the rewards of success moving to gain what is possible to get from talent. They have none, so they have to see it manifested and then they capture it for their benefit. They have no other access to the good stuff. All industries, human endevors, work this way. All power structures, all groups.
iandanforth 7y ago
This is a poor argument attacking a straw man. Each of the cited papers discussing "hero" projects are in the context of medium to large organisations. While open source GitHub projects are frequently self-contained tools or libraries. Equating the two is a monumental and unsupported jump.
- bartread 7y ago
  I'm glad I'm not the only one who thinks this is nonsense. I wrote a fairly long comment, which you (might) find elsewhere in the discussion, then started reading the other comments and was starting to wonder what other people were seeing that I wasn't. Short version: the OSS versus every other type of software project comparison seems very apples and oranges.
- falcongod082 7y ago
  This isn't an argument, it's a description. I suspect you didn't read the paper.
revvx 7y ago
It's the second time I mention Fred Brooks on HN today, but he dedicates a chapter in Mythical Man-Month that agrees with the assertion of the article: > Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Other team members perform other tasks, and some of those even administrative (!), but all of them supporting the "vision" of the surgeon. IMO this is a healthier way of communicating roles, avoiding fights and training juniors. It's better than the "everyone is replaceable" mindset companies have this day.
- colechristensen 7y ago
  You can (should) also give leadership to juniors on appropriately sized projects. That's how you make better programmers.
  - theshrike79 7y ago
    You should give leadership/ownership/responsibility of smaller components of the larger vision to juniors or people new to the team.
  - GrumpyNl 7y ago
    Most companies want more business value, they dont care for better programmers.
    - jdc 7y ago
      Next time said companies complain about a talent shortage, they would do well to remember TANSTAAFL.
      - aerophilic 7y ago
        Because I had to look it up: TANSTAAFL = There ain't no such thing as a free lunch
yuhe00 7y ago
Maybe I've just been unfortunate/fortunate, but in 6 years as a software developer on all kinds of projects, I've never once worked on a project where even two people share the major contributions to a single repo. Either I run away with one part of the project or someone else does while I work on some other part. Usually split between frontend/backend/devops (webstuff) or app/libraries/tooling. We obviously plan and discuss how the different parts of the projects work together, and we do make contributions to the other repos, but these are usually minor. I don't necessarily see it as a bad thing. It just feels the most natural, reduces friction and the need to communicate minute details. Ownership is also important. The downside of this is that some part of the project might fall apart if someone leaves, because no one else can take over.
- pojzon 7y ago
  > The downside of this is that some part of the project might fall apart if someone leaves, because no one else can take over. This is the reason, i think, corporate world HATES with passion such devs. Even tho they need them to meet deadlines. It also gives a bit too much power in negotiating to the employee which is also seen as "bad" in corpo.
  - luckylion 7y ago
    > This is the reason, i think, corporate world HATES with passion such devs. Which is the right attitude, imho. Even if that person loves the company and would never leave - what if a bus runs them over? On a large scale, consistency is more important than excellence. You need to be able to plan, "if that guy stays, the project will be done in 4 weeks, but if he leaves, it will take four years" just won't work, because you cannot rely on it. It's much better to be able to say "it will be done in 12-14 weeks" with high confidence. Sure, your whole dev team might get run over and spoil your plans, but that's really a case of force majeur.
    - rabidrat 7y ago
      Okay, so let's be optimistic and say a team of 4 can do in 12 weeks what that one dev could do in 4 weeks. 48 dev-weeks vs 4 dev-weeks. Do you think it's reasonable for a project to cost 10x as much just for that precious consistency? Not to mention that longer projects with larger teams have higher variability in outcome, with most projects overshooting by 100% or more. Is this really the right attitude then?
eshch 7y ago
apart from questionable choices of data to analyze (open-source has its own specific), the study proves only that heroes are good in hero projects. perfect.
stevebmark 7y ago
I wonder _why_ hero projects are more bug free. I could probably write lots of terrible but bug free code on a personal project, because I know where all the flaws are and avoid them. If I invited more developers to work on this codebase, of course there would be more bugs, because the code quality is so bad. If I wrote good abstractions, types, and documentation, theoretically others contributing to the code would write less bugs too.
- LoSboccacc 7y ago
  > and documentation that's the gist of it, abstractions are always imperfect in some way and leave the door open for interpretation, at which point if team member don't communicate each module intent efficiently code responsibilities get mixed and entropy rise dramatically, causing more bug per line of code written. imho an important figure on large projects that is largely ignored or conflated with "the architects" is the oracle, or the guy people ask where new feature/code should go. not in term of application structure or component design, but at a lower level, at modules and interfaces level.
jackconnor 7y ago
Having worked on many, many software projects myself, this is 100% accurate. One good programmer who is intensely focused and interested in a project is worth 20 - 50 (or more) programmers who are just code monkeying it without really giving a shit. This is why a small, passionate startup team can consistently build better products than large corporations. Much better products.
- HeWhoLurksLate 7y ago
  As someone who has generated 99% of the code- not counting StackOverflow- for a project, it honestly is a double-edged sword- I can't rely on anyone else to fix anything, but when I break things the impact is rather minimal.
- Data_Junkie 7y ago
  There is no substitute for caring, and people consistently, dramatically underestimate the difference in thought that happens in people who care and people who don't. Anytime I'm asked why someone should listen to me and not someone else I tell them "because I care". It is really all it takes to separate from the incompetent, so few understand what caring does.
  - deleted 7y ago
    [deleted]
  - jackconnor 7y ago
    Absolutely. I'm sure there are many reasons for this, but a big one i always see is attention to detail. People who really care are obsessed with getting all the details right, and hate bugginess, bad ux, and other issues typical of crappy software. Big projects with no real owner may have lots of programmers, but none of them care so much that they want to get in the really deep weeds to make the thing a truly amazing software experience.
    - Data_Junkie 7y ago
      And that is because there is always more to care about, just as true love has no end.
m0zg 7y ago
"Hero" is a bad name for it, but one or two people on the team need to _really_ understand what is it that needs to be done, and the management needs to understand that those people _understand_, and support them. At least 80% of any given team either don't understand what needs to be done or don't give a shit, or both. Leaving such folks to their own devices is a very wasteful and counterproductive exercise.
yawniek 7y ago
likely this is also one of the core reasons why microservices are so successful these days. they allow having many small hero developers that create replaceable components fast.
bartread 7y ago
> A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers. ... We identify the heroes developer communities in 1100+ open source GitHub projects. My scepticism has been piqued to the extent that I call b######t. Open source projects. Projects contributed to by people in their spare time, or perhaps with some corporate backing with developers on the payroll, and often with quite different governance models. Should we therefore be surprised at the widely varying levels of contribution? Should we be surprised that those who do more work on the projects tend to make contributions resulting in fewer bugs, perhaps because they have a much better understanding of the projects due to their greater familiarity with them? Whatever: OSS projects with contributions coming in from all manner of sources outside the core team aren't necessarily terribly similar to having a team of 6 - 8 working on a project full time within a company. The only similarity being that a relatively small core team do most (or all) of the work. Colour me not even slightly surprised. My blunt conclusion is that the idea software projects "need" so-called "hero" developers is extremely questionable based on the data presented[1]. [1] Granted I've done no more than skim the paper but this comment, from page 3, amused me: "Most prior researchers deprecate heroism in software projects." Really? Do they now?
- falcongod082 7y ago
  You're calling bullshit on a paper defining the terms that it is using in the paper?
  - bartread 7y ago
    The headline's been changed since I submitted. I was calling bullshit on the fact that it appeared to be drawing general conclusions about all software projects based on a survey of open source software projects, which often operate under different conditions to those in commercial organisations. The abstract and title of the paper are somewhat baity, as others have pointed out, but the headline here now reflects the fact that the paper only represents OSS projects hosted in GitHub.
    - falcongod082 7y ago
peter_d_sherman 7y ago
This is the 80/20 rule, except applied to the proportional contributions made by a group of developers on a given project, rather than how time is allocated relative to problem solving related to software development... You know, a similar argument could be made for history... that 80% of societal progress was created by 20% of the individuals living in that society...
Guthur 7y ago
I feel this is the Pareto efficiency Isa play which is a very common phenomenon.
dlkf 7y ago
I believe the conclusion is basically true, but I also feel that sampling from the Github project showcase list induces a selection bias that is going to support it. The analysis would be more convincing if the authors had gained access to some enterprise codebases whose contribution graphs were more evenly distributed than their open source counterparts.
gchamonlive 7y ago
In larger projects, each module or discrete functionality works like what's being described in the article. There will always be a handful of programmers, most likely coordinating other programmers, that intimately know that module. That is OK and in many occasions development and intervention, from concept to implementation and then test and release to production, can be sped up, but it must be taken into account that it also lowers the so called truck factor (I like to call it lottery factor, in which a developer wins a lottery ticket, becomes a multi millionaire overnight and leaves the project, rendering hopeless all those parts he had exclusive knowledge) I guess then the goal is to find balance between having heroes and increasing the lottery factor of the team.
taeric 7y ago
I find it silly they designate these as heroes. Seems simpler to say that most projects are small enough that a single person can do the majority of the work. Not shockingly, most smaller projects don't fail that heavily. Add in the extra work that collaboration necessarily brings to the table, and it isn't that shocking that things both slow down and get more error prone. At a certain size, though, this is worth the cost of admission. More, it isn't like we call all projects done by fewer individuals heroes. We have authors, not "writing heroes." And the author joke is meant to point out that the vast majority of what you read has a single person's name on it, but without the editors and other workers involved, that book would never have come about.
- bjourne 7y ago
  Yes, but that brings into question how large a project needs to be for the hero model not to be feasible anymore. They surveyed over 1 100 projects and I would guess a significant portion of them would be counted as "large". I found their raw data on github here, https://github.com/ai-se/Git_miner https://github.com/ai-se/Git_miner, although it is in some weird .xlsx format so I can't verify if my guess is true.
  - reboog711 7y ago
    .xlsx is a Microsoft Excel file. I bet you can open it with Google Docs, LibreOffice, or something similar.
    - mr__y 7y ago
      You can also change extension to .zip, unzip it and read individual xml files from worksheets/ subdirectory. However, because of the horrible schema in those xml this is probably a really bad idea to go that way. It's way better to use the software that parent mentioned
- mruniverse 7y ago
  The "hero" phrase is fine. It just refers to the devs doing 80% of the work.
killjoywashere 7y ago
Probably tangential, but I think this ties in nicely with the study about the effectiveness of Reddit deleting toxic subs (1). Leadership does in fact matter. But at the same time, all politics are local. (1) https://news.ycombinator.com/item?id=19770237 https://news.ycombinator.com/item?id=19770237
benkuhn 7y ago
Everyone who's interpreting this in the context of full-time work / the traditional notion of "10x programmer" (i.e. ~every toplevel commenter) should read the abstract: > A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers... We identify the heroes developer communities in 1100+ open source GitHub projects. (emphasis mine) Of course nearly every Github project is going to have heroes--we call them "maintainers." This study is totally unsurprising and totally non-generalizable to professional teams working on proprietary software. The use of the term "heroes" in the abstract is massively misleading and tendentious, IMO.
- deleted 7y ago
  [deleted]
- dang 7y ago
  Ok, we've added "Github" to the title above. Edit: and maybe we can make the phrasing a bit less tendentious. Bad sign when paper titles need debaiting, but that's the trend.
  - anonytrary 7y ago
    "The 80/20 rule applied to Github projects"?
  - gmolau 7y ago
    This was my first submission here, but is it really helpful to change the title of a published research paper? Just because some commenters didn't like it, and at the cost of this discussion now being harder to find when people google the paper?
    - dang 7y ago
      The site guidelines say: "Please use the original title, unless it is misleading or linkbait" (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html). Being the title of a published research paper doesn't immunize against those things, unfortunately, and based on the comments posted here, that title was arguably both. We know from long experience why it's helpful to make such a change: if we don't, people will keep complaining about and bickering about the title. Editing is the only way to soothe title fever. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0&query=by:dang%20title%20fever https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme... This thread still comes up if I google the paper's original title, and is the #1 result if I google "software project heroes". p.s. Welcome to HN!
tanilama 7y ago
What is the opposite of hero project? I didn't see one project in my life that doesn't have a BDFL style person in charge for my 10 years programming experience...
Data_Junkie 7y ago
All good teams revolve around stars. Talented brains can create more value that two hands can do, and the organization exist to help them win. Nothing new.
myth2018 7y ago
That matter has caught my attention some other times. I'm aware of dozens of projects where such "hero developer" phenomenon happened and it's really interesting (some I worked for, some I knew by other people). I ask myself why that happens. No doubt that variations in developers' talents is a factor. But I think there are some social forces operating there as well. I have become the hero of four projects after the previous hero had left. And I have also already arrived in projects with pre-established heroes. Despite I've been able to be a reasonable hero whenever I ended in such position, the other times when I worked with established heroes, they were condescending over me and the rest of the team. There has always been that trend to patronize and to be a plain jerk. That was annoying. I knew I could contribute more and maybe even to help to herorize the project. But, simply put, there weren't minimal social conditions for that to happen. Maybe the heroing concentration would dilute a bit by improving social conditions.
glenecho123 7y ago
where can i find trading heroes pinder321@gmail.com
glenecho123 7y ago
wher can I find trading heroes pinder321@gmail.com
euske 7y ago
The result itself is unsurprising, but I'm curious of what caused their low bug rate ("code quality" in their term). They haven't looked at the actual code, but I guess that code consistency plays a big role for reducing potential bugs, and it's easily achieved with having fewer developers in a team. Also this is not contradictory to sayings like "a lot of eyeballs make software better" because I believe eyeballs mainly contribute to bug detection, but not bug prevention. Edit: After posting this, I dug into this problem a bit more. I think code consistency is less important between modules (in a large project). But this requires a premise that these modules are independent enough and they don't need much communication each other. This line of thought is pointed out by this SO question. https://softwareengineering.stackexchange.com/questions/190649/whats-the-right-balance-between-code-consistency-and-code-improvement/190658#190658 https://softwareengineering.stackexchange.com/questions/1906...
graphememes 7y ago
Did we really need a study to come to this conclusion? Heros are called maintainers, or creators. This is every project. This is what this study concludes. Does the world not understand this?
phlimflam 7y ago
It's obvious that the projects with the lowest bug counts are maintained by one person with a vision. Projects that accept any drive-by pull request without serious scrutiny inevitably suffer code quality and consistency issues. It is often more important to know what features to exclude from a project as knowing what to include. The "heroes" know the history of the project and are responsible for a consistent design.
3xblah 7y ago
"The real hero of programming is the one who writes negative code." - Doug McIlroy "[T]he meaning of negative code is taken to be similar to the famous Apple developer team anecdote (i.e., when a change in a program source makes the number of lines of code decrease ('negative' code), while its overall quality, readability or speed improves)." - http://en.wikipedia.org/wiki/Douglas_McIlroy http://en.wikipedia.org/wiki/Douglas_McIlroy "When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw's region calculation routines to be six times faster and 2000 lines shorter, he put "-2000" on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied." - http://www.computerhistory.org/highlights/macpaint/ http://www.computerhistory.org/highlights/macpaint/ "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." - Pete Kirkham
qznc 7y ago
There is certainly some survivorship bias involved. The filter (50+ weeks of activity, 8+ contributors, etc) only selects somewhat successful software projects. Big professional software development also emphasizes reliable planning, requirements engineering, and documented processes. In contrast, most open source projects begin in a cowboy style with a single person starting to code without requirements and processes and often not even much of a plan. This lightweight process implies a lot more risk and indeed most of these projects fail. That is fine. The free software world rather goes with this evolutionary approach. I wonder if there is any company which works in a similar way. Start lots of projects with a fraction of the resources. Be fine with most projects failing. I guess not because this approach is hardly compatible with career development. Googles 20% rule might be considered a step in that direction.

337 points by gmolau 7y ago

Very interesting. But that probably doesn't translate to professional projects where people have more incentive to contribute and core contributors the obligation to onboard and mentor new hires...

convolvatron 7y ago
indeed. i dont think its wise to dismiss the corporate aversion to 'heroes'. while its certainly possible to make an outsized contribution without getting burned out or devaluing other contributors, thats often not what happens.
- nitrogen 7y ago
  devaluing other contributors Maybe this isn't what you meant, but why is it that human beings see someone they know producing a lot of value as diminishing the value produced by others, especially in technical matters?
  - wolco 7y ago
    Because people compare and if someone is doing a lot morr than everyone else it makes everyone look bad. Why? Because the mba will see a metric elevated and use that to define a norm. Now they only want to hire 10x performers. They don't know how to find them so they invent this complex hiring process that filters out so many good candidates they have no chance of ever finding that 10x developer. They settle on the fake 10x who speaks well and presents all of the right signals. The dev comes in and struggles and blames the code/past developer/way something is done and claims a rewrite is needed in a new and trendy language. This prompts a huge rewrite that takes place over a year at the end of which its determined that nothing works and that project gets cancelled. By this point that developer has been promoted to your manager.
- diminoten 7y ago
  Isn't this paper saying exactly the opposite, though? That it does happen, and quite often?
falcongod082 7y ago
If you think that "why" someone contributes is meaningful, I'm curious how you think that professional projects (whatever that means) and whatever arbitrary metric is being used to encourage incentive would give a different result.
- jrumbut 7y ago
  For instance, on a minuscule open source project of mine, I wrote all the code and another developer has (kindly) stepped up and managed upgrades to one of the dependencies, bumping the version number when it's time to do so. If he and I were employed together to work on this project, a workload distribution of me writing and maintaining the entire codebase (minus one line) and him coming by every couple months to update a version number would not be a very fair or realistic division of labor. The open source development process is very different from anything else. None of my projects at work have a long tail of contributors submitting comment typo fixes.
  - diminoten 7y ago
    It'd be much more fair if the project at your job started out as a proof-of-concept that you wrote, while the other dev worked on other things. Once your proof-of-concept grew into something management wanted, you'd probably still be writing a lot of the code, and the other developer would be contributing, but in the realm of 20% of the codebase, at least to start (and according to this article, that wouldn't change).
    - jrumbut 7y ago
      You're right, and I don't doubt the value of studying open source projects or that it's the best that can be done given the data available, but there are limitations on how much light this data can shed on the great mass of code being written within organizations. Maybe the results do apply to the situation you describe, I'd be curious to know that.
- jeandejean 7y ago
  I'd say two things, the first is that if you're not paid, you don't have that much incentive to contribute hardly so it's no surprise that most OS projects are maintained by a handful of (great indeed) highly motivated developers. Second is that it's something widely known that developers are not flexible, so if they're in charge of their baby, they won't make so many efforts to encourage outsiders contributions. Whereas in a corp environment, managers and other devs should make sure it doesn't become an obstacle to contributions. That's not very precise but I think people can relate to what I said.
jcriddle4 7y ago
"...In 2018, Agrawal...studied...661 open source and 171 in-house proprietary projects. In that sample, over 89% of all projects were hero-based..." In theory a "professional" project would want efficiency so all developers contributing fairly equally however the data does not support that. Wide variances in developer productivity are widely documented. I would think open source projects also have to work to onboard and mentor new developers or they would eventually die out. You might say that professional projects are possibly larger but the study indicated size didn't matter "...the bug injection distributions of heroes and nonheroes is barely changed after stratifying the data according to project size. Hence, when discussing the external validity of these conclusions, we need not explore issues of team size and hero prevalence." I don't see any data that suggests this study would not generalize to professional projects.

deleted 7y ago

[deleted]

kartan 7y ago

> A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers. If that 20% leave, the other 80% would contribute equally or the ration 20/80 will be preserved? This seams a feedback loop. Once a developer has written more code than others is in a better position to write even more. If that is the case "hero developer" is a floating position, depending so much on your skill and how much time you have been working in a project and other circumstances. > Organizationsshould reflect on better ways to find and retain more ofthese software heroes. I had this discussion recently. If you create a team of "heroes" all become way slower than when they were in different teams. My personal conclusion, and the way of working that I try to implement at work is that small independent projects allow for developers to be fast and reliable. If your project is correctly divided, anyone can contribute ( at their level of expertise). If you have a big complex projects then old-timers that created originally the code are the only ones that can work with it efficiently if no other developers make big changes (reducing the ability of other developers to contribute independently of their level of skill). So, before going in search of "heroes" think if your projects are correctly divided. And think about the risk that you create when a "hero developer" is needed and leaves.

svaha1728 7y ago
I recently left a company organized in this way. It was quite disheartening: small changes would break the code in multiple ways, hundreds of public functions, no interfaces. The architect was seen as a ‘super’ developer...
- timClicks 7y ago
  Perhaps an ideal scenario would be to have a single 'super' developer have relatively free reign, under the condition that she can explain the code/architecture to others effectively also.
  - duncan-donuts 7y ago
    Yeah, definitely not an ideal scenario.

cookiecaper 7y ago

> A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers. Where does this definition come from? It sounds quite typical to me. Even in large projects like the Linux kernel, if you break them down into comprehensible units and subsystems, I would expect you'd find essentially the same thing. The vast majority of projects likely meet the "hero project" threshold defined above, whether they're good or bad. I don't know of any movement to specifically prevent having primary contributors; the main interest from the corporate world is ensuring that primary contributors can be cycled as necessary. This doesn't seem like news in any way. I don't want to be unduly dismissive as I haven't read the paper, but I think I'm catching a distinctive whiff of "publish or perish" in the vicinity...

xrd 7y ago

This is really fascinating. If true, it suggests that big companies with huge teams that try to force the entire team into equal contribution metrics are creating stress that might not help the team, nor lead to fewer bugs (big surprise). I've never been on a team which was set up to truly recognize the value different forms of contribution, like writing tests, or removing code, or simplifying it, or other things which would not count towards the hero metric presented here. As an industry we just don't think about alternative narratives to "let's make sure everyone is an equal contributor..."

revvx 7y ago
Code Reviews are also devalued, to the point of most developers I worked with considering it a chore.
- xrd 7y ago
  That's a great point. The cost of doing that is never calculated and the impact is so positive.
asimpletune 7y ago
Yeah that’s a very interesting observation, and sort of corroborates my own anecdata. More specifically, when projects are in there infancy, and there’s a lot of risk associated with working on them, I feel that management tends to stay away, which is how these heroes originate. Then, after it’s obvious that project will succeed and it’s merits are overwhelming, you see this shift in project governance/responsibility towards a more corporate mode. However, like you said, that’s probably counter productive and just creates stress and tension. If anything, I think sometimes management has an uncontrollable tendency to position itself strategically in these gatekeeper roles, whereas in open source they don’t get to do that simply by virtue of being someone’s boss, so you don’t see that same trend, as the paper argues. Not sure if that makes sense, I quickly typed this on my phone.
- Data_Junkie 7y ago
  That is the untalented who are interested in the rewards of success moving to gain what is possible to get from talent. They have none, so they have to see it manifested and then they capture it for their benefit. They have no other access to the good stuff. All industries, human endevors, work this way. All power structures, all groups.

iandanforth 7y ago

This is a poor argument attacking a straw man. Each of the cited papers discussing "hero" projects are in the context of medium to large organisations. While open source GitHub projects are frequently self-contained tools or libraries. Equating the two is a monumental and unsupported jump.

bartread 7y ago
I'm glad I'm not the only one who thinks this is nonsense. I wrote a fairly long comment, which you (might) find elsewhere in the discussion, then started reading the other comments and was starting to wonder what other people were seeing that I wasn't. Short version: the OSS versus every other type of software project comparison seems very apples and oranges.
falcongod082 7y ago
This isn't an argument, it's a description. I suspect you didn't read the paper.

revvx 7y ago

It's the second time I mention Fred Brooks on HN today, but he dedicates a chapter in Mythical Man-Month that agrees with the assertion of the article: > Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Other team members perform other tasks, and some of those even administrative (!), but all of them supporting the "vision" of the surgeon. IMO this is a healthier way of communicating roles, avoiding fights and training juniors. It's better than the "everyone is replaceable" mindset companies have this day.

colechristensen 7y ago
You can (should) also give leadership to juniors on appropriately sized projects. That's how you make better programmers.
- theshrike79 7y ago
  You should give leadership/ownership/responsibility of smaller components of the larger vision to juniors or people new to the team.
- GrumpyNl 7y ago
  Most companies want more business value, they dont care for better programmers.
  - jdc 7y ago
    Next time said companies complain about a talent shortage, they would do well to remember TANSTAAFL.
    - aerophilic 7y ago
      Because I had to look it up: TANSTAAFL = There ain't no such thing as a free lunch

yuhe00 7y ago

Maybe I've just been unfortunate/fortunate, but in 6 years as a software developer on all kinds of projects, I've never once worked on a project where even two people share the major contributions to a single repo. Either I run away with one part of the project or someone else does while I work on some other part. Usually split between frontend/backend/devops (webstuff) or app/libraries/tooling. We obviously plan and discuss how the different parts of the projects work together, and we do make contributions to the other repos, but these are usually minor. I don't necessarily see it as a bad thing. It just feels the most natural, reduces friction and the need to communicate minute details. Ownership is also important. The downside of this is that some part of the project might fall apart if someone leaves, because no one else can take over.

pojzon 7y ago
> The downside of this is that some part of the project might fall apart if someone leaves, because no one else can take over. This is the reason, i think, corporate world HATES with passion such devs. Even tho they need them to meet deadlines. It also gives a bit too much power in negotiating to the employee which is also seen as "bad" in corpo.
- luckylion 7y ago
  > This is the reason, i think, corporate world HATES with passion such devs. Which is the right attitude, imho. Even if that person loves the company and would never leave - what if a bus runs them over? On a large scale, consistency is more important than excellence. You need to be able to plan, "if that guy stays, the project will be done in 4 weeks, but if he leaves, it will take four years" just won't work, because you cannot rely on it. It's much better to be able to say "it will be done in 12-14 weeks" with high confidence. Sure, your whole dev team might get run over and spoil your plans, but that's really a case of force majeur.
  - rabidrat 7y ago
    Okay, so let's be optimistic and say a team of 4 can do in 12 weeks what that one dev could do in 4 weeks. 48 dev-weeks vs 4 dev-weeks. Do you think it's reasonable for a project to cost 10x as much just for that precious consistency? Not to mention that longer projects with larger teams have higher variability in outcome, with most projects overshooting by 100% or more. Is this really the right attitude then?

eshch 7y ago

apart from questionable choices of data to analyze (open-source has its own specific), the study proves only that heroes are good in hero projects. perfect.

stevebmark 7y ago

I wonder _why_ hero projects are more bug free. I could probably write lots of terrible but bug free code on a personal project, because I know where all the flaws are and avoid them. If I invited more developers to work on this codebase, of course there would be more bugs, because the code quality is so bad. If I wrote good abstractions, types, and documentation, theoretically others contributing to the code would write less bugs too.

LoSboccacc 7y ago
> and documentation that's the gist of it, abstractions are always imperfect in some way and leave the door open for interpretation, at which point if team member don't communicate each module intent efficiently code responsibilities get mixed and entropy rise dramatically, causing more bug per line of code written. imho an important figure on large projects that is largely ignored or conflated with "the architects" is the oracle, or the guy people ask where new feature/code should go. not in term of application structure or component design, but at a lower level, at modules and interfaces level.

jackconnor 7y ago

Having worked on many, many software projects myself, this is 100% accurate. One good programmer who is intensely focused and interested in a project is worth 20 - 50 (or more) programmers who are just code monkeying it without really giving a shit. This is why a small, passionate startup team can consistently build better products than large corporations. Much better products.

HeWhoLurksLate 7y ago
As someone who has generated 99% of the code- not counting StackOverflow- for a project, it honestly is a double-edged sword- I can't rely on anyone else to fix anything, but when I break things the impact is rather minimal.
Data_Junkie 7y ago
There is no substitute for caring, and people consistently, dramatically underestimate the difference in thought that happens in people who care and people who don't. Anytime I'm asked why someone should listen to me and not someone else I tell them "because I care". It is really all it takes to separate from the incompetent, so few understand what caring does.
- deleted 7y ago
  [deleted]
- jackconnor 7y ago
  Absolutely. I'm sure there are many reasons for this, but a big one i always see is attention to detail. People who really care are obsessed with getting all the details right, and hate bugginess, bad ux, and other issues typical of crappy software. Big projects with no real owner may have lots of programmers, but none of them care so much that they want to get in the really deep weeds to make the thing a truly amazing software experience.
  - Data_Junkie 7y ago
    And that is because there is always more to care about, just as true love has no end.

m0zg 7y ago

"Hero" is a bad name for it, but one or two people on the team need to _really_ understand what is it that needs to be done, and the management needs to understand that those people _understand_, and support them. At least 80% of any given team either don't understand what needs to be done or don't give a shit, or both. Leaving such folks to their own devices is a very wasteful and counterproductive exercise.

yawniek 7y ago

likely this is also one of the core reasons why microservices are so successful these days. they allow having many small hero developers that create replaceable components fast.

bartread 7y ago

> A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers. ... We identify the heroes developer communities in 1100+ open source GitHub projects. My scepticism has been piqued to the extent that I call b######t. Open source projects. Projects contributed to by people in their spare time, or perhaps with some corporate backing with developers on the payroll, and often with quite different governance models. Should we therefore be surprised at the widely varying levels of contribution? Should we be surprised that those who do more work on the projects tend to make contributions resulting in fewer bugs, perhaps because they have a much better understanding of the projects due to their greater familiarity with them? Whatever: OSS projects with contributions coming in from all manner of sources outside the core team aren't necessarily terribly similar to having a team of 6 - 8 working on a project full time within a company. The only similarity being that a relatively small core team do most (or all) of the work. Colour me not even slightly surprised. My blunt conclusion is that the idea software projects "need" so-called "hero" developers is extremely questionable based on the data presented[1]. [1] Granted I've done no more than skim the paper but this comment, from page 3, amused me: "Most prior researchers deprecate heroism in software projects." Really? Do they now?

falcongod082 7y ago
You're calling bullshit on a paper defining the terms that it is using in the paper?
- bartread 7y ago
  The headline's been changed since I submitted. I was calling bullshit on the fact that it appeared to be drawing general conclusions about all software projects based on a survey of open source software projects, which often operate under different conditions to those in commercial organisations. The abstract and title of the paper are somewhat baity, as others have pointed out, but the headline here now reflects the fact that the paper only represents OSS projects hosted in GitHub.
  - falcongod082 7y ago

peter_d_sherman 7y ago

This is the 80/20 rule, except applied to the proportional contributions made by a group of developers on a given project, rather than how time is allocated relative to problem solving related to software development... You know, a similar argument could be made for history... that 80% of societal progress was created by 20% of the individuals living in that society...

Guthur 7y ago

I feel this is the Pareto efficiency Isa play which is a very common phenomenon.

dlkf 7y ago

I believe the conclusion is basically true, but I also feel that sampling from the Github project showcase list induces a selection bias that is going to support it. The analysis would be more convincing if the authors had gained access to some enterprise codebases whose contribution graphs were more evenly distributed than their open source counterparts.

gchamonlive 7y ago

In larger projects, each module or discrete functionality works like what's being described in the article. There will always be a handful of programmers, most likely coordinating other programmers, that intimately know that module. That is OK and in many occasions development and intervention, from concept to implementation and then test and release to production, can be sped up, but it must be taken into account that it also lowers the so called truck factor (I like to call it lottery factor, in which a developer wins a lottery ticket, becomes a multi millionaire overnight and leaves the project, rendering hopeless all those parts he had exclusive knowledge) I guess then the goal is to find balance between having heroes and increasing the lottery factor of the team.

taeric 7y ago

I find it silly they designate these as heroes. Seems simpler to say that most projects are small enough that a single person can do the majority of the work. Not shockingly, most smaller projects don't fail that heavily. Add in the extra work that collaboration necessarily brings to the table, and it isn't that shocking that things both slow down and get more error prone. At a certain size, though, this is worth the cost of admission. More, it isn't like we call all projects done by fewer individuals heroes. We have authors, not "writing heroes." And the author joke is meant to point out that the vast majority of what you read has a single person's name on it, but without the editors and other workers involved, that book would never have come about.

bjourne 7y ago
Yes, but that brings into question how large a project needs to be for the hero model not to be feasible anymore. They surveyed over 1 100 projects and I would guess a significant portion of them would be counted as "large". I found their raw data on github here, https://github.com/ai-se/Git_miner https://github.com/ai-se/Git_miner, although it is in some weird .xlsx format so I can't verify if my guess is true.
- reboog711 7y ago
  .xlsx is a Microsoft Excel file. I bet you can open it with Google Docs, LibreOffice, or something similar.
  - mr__y 7y ago
    You can also change extension to .zip, unzip it and read individual xml files from worksheets/ subdirectory. However, because of the horrible schema in those xml this is probably a really bad idea to go that way. It's way better to use the software that parent mentioned
mruniverse 7y ago
The "hero" phrase is fine. It just refers to the devs doing 80% of the work.

killjoywashere 7y ago

Probably tangential, but I think this ties in nicely with the study about the effectiveness of Reddit deleting toxic subs (1). Leadership does in fact matter. But at the same time, all politics are local. (1) https://news.ycombinator.com/item?id=19770237 https://news.ycombinator.com/item?id=19770237

benkuhn 7y ago

Everyone who's interpreting this in the context of full-time work / the traditional notion of "10x programmer" (i.e. ~every toplevel commenter) should read the abstract: > A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers... We identify the heroes developer communities in 1100+ open source GitHub projects. (emphasis mine) Of course nearly every Github project is going to have heroes--we call them "maintainers." This study is totally unsurprising and totally non-generalizable to professional teams working on proprietary software. The use of the term "heroes" in the abstract is massively misleading and tendentious, IMO.

deleted 7y ago
[deleted]
dang 7y ago
Ok, we've added "Github" to the title above. Edit: and maybe we can make the phrasing a bit less tendentious. Bad sign when paper titles need debaiting, but that's the trend.
- anonytrary 7y ago
  "The 80/20 rule applied to Github projects"?
- gmolau 7y ago
  This was my first submission here, but is it really helpful to change the title of a published research paper? Just because some commenters didn't like it, and at the cost of this discussion now being harder to find when people google the paper?
  - dang 7y ago
    The site guidelines say: "Please use the original title, unless it is misleading or linkbait" (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html). Being the title of a published research paper doesn't immunize against those things, unfortunately, and based on the comments posted here, that title was arguably both. We know from long experience why it's helpful to make such a change: if we don't, people will keep complaining about and bickering about the title. Editing is the only way to soothe title fever. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0&query=by:dang%20title%20fever https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme... This thread still comes up if I google the paper's original title, and is the #1 result if I google "software project heroes". p.s. Welcome to HN!

tanilama 7y ago

What is the opposite of hero project? I didn't see one project in my life that doesn't have a BDFL style person in charge for my 10 years programming experience...

Data_Junkie 7y ago

All good teams revolve around stars. Talented brains can create more value that two hands can do, and the organization exist to help them win. Nothing new.

myth2018 7y ago

That matter has caught my attention some other times. I'm aware of dozens of projects where such "hero developer" phenomenon happened and it's really interesting (some I worked for, some I knew by other people). I ask myself why that happens. No doubt that variations in developers' talents is a factor. But I think there are some social forces operating there as well. I have become the hero of four projects after the previous hero had left. And I have also already arrived in projects with pre-established heroes. Despite I've been able to be a reasonable hero whenever I ended in such position, the other times when I worked with established heroes, they were condescending over me and the rest of the team. There has always been that trend to patronize and to be a plain jerk. That was annoying. I knew I could contribute more and maybe even to help to herorize the project. But, simply put, there weren't minimal social conditions for that to happen. Maybe the heroing concentration would dilute a bit by improving social conditions.

glenecho123 7y ago

where can i find trading heroes pinder321@gmail.com

glenecho123 7y ago

wher can I find trading heroes pinder321@gmail.com

euske 7y ago

The result itself is unsurprising, but I'm curious of what caused their low bug rate ("code quality" in their term). They haven't looked at the actual code, but I guess that code consistency plays a big role for reducing potential bugs, and it's easily achieved with having fewer developers in a team. Also this is not contradictory to sayings like "a lot of eyeballs make software better" because I believe eyeballs mainly contribute to bug detection, but not bug prevention. Edit: After posting this, I dug into this problem a bit more. I think code consistency is less important between modules (in a large project). But this requires a premise that these modules are independent enough and they don't need much communication each other. This line of thought is pointed out by this SO question. https://softwareengineering.stackexchange.com/questions/190649/whats-the-right-balance-between-code-consistency-and-code-improvement/190658#190658 https://softwareengineering.stackexchange.com/questions/1906...

graphememes 7y ago

Did we really need a study to come to this conclusion? Heros are called maintainers, or creators. This is every project. This is what this study concludes. Does the world not understand this?

phlimflam 7y ago

It's obvious that the projects with the lowest bug counts are maintained by one person with a vision. Projects that accept any drive-by pull request without serious scrutiny inevitably suffer code quality and consistency issues. It is often more important to know what features to exclude from a project as knowing what to include. The "heroes" know the history of the project and are responsible for a consistent design.

3xblah 7y ago

"The real hero of programming is the one who writes negative code." - Doug McIlroy "[T]he meaning of negative code is taken to be similar to the famous Apple developer team anecdote (i.e., when a change in a program source makes the number of lines of code decrease ('negative' code), while its overall quality, readability or speed improves)." - http://en.wikipedia.org/wiki/Douglas_McIlroy http://en.wikipedia.org/wiki/Douglas_McIlroy "When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw's region calculation routines to be six times faster and 2000 lines shorter, he put "-2000" on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied." - http://www.computerhistory.org/highlights/macpaint/ http://www.computerhistory.org/highlights/macpaint/ "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." - Pete Kirkham

qznc 7y ago

There is certainly some survivorship bias involved. The filter (50+ weeks of activity, 8+ contributors, etc) only selects somewhat successful software projects. Big professional software development also emphasizes reliable planning, requirements engineering, and documented processes. In contrast, most open source projects begin in a cowboy style with a single person starting to code without requirements and processes and often not even much of a plan. This lightweight process implies a lot more risk and indeed most of these projects fail. That is fine. The free software world rather goes with this evolutionary approach. I wonder if there is any company which works in a similar way. Start lots of projects with a fraction of the resources. Be fine with most projects failing. I guess not because this approach is hardly compatible with career development. Googles 20% rule might be considered a step in that direction.