5 ms·

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

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!
    - gmolau 7y ago
      Not trying to start an argument over words, but that seems a bit unfair to the authors. Their title promised they would analyze 1100 projects, and that is what they did. Being accused of misleading or even linkbaiting their readers by (let's be honest) armchair scientists imho doesn't reflect well on this platform.
      - Illniyar 7y ago
        Just because it's true doesn't mean it isn't misleading. Consider if they had the same title but only analyzed projects with a single contributor or pet projects. By only including open source projects they've limited the ability to generalize their conclusions, which they themselves allude to in their "threats to validity" section. Changing the title simply better reflects the content of the article, which the researchers didn't do (sometimes this is due to external pressures such as university PR departments, but I doubt is the case here)
      - dang 7y ago
        The number of projects analyzed was not the issue, though "1100+" does add to the impression of the title being hotrodded a bit. The criticisms HN users made of the title, that I heard, were first that the paper looks only at open-source projects on Github, which is not representative of software projects in general, while the title refers to software projects in general. Second, "Why X needs Y" (where Y is a sensational word like "heroes") is a linkbait trope, easily recognized by anyone who spends time around internet articles, as well as an overselling of the finding. An analysis of commit rates on Github does not explain why, it shows that—which is great, and which we edited the title to represent more clearly. On HN, an article does not get a pass to use these tricks just because it's a paper on Arxiv. The internet game is to inflate titles to oversell the body, and the HN game is to rejig them back to scale, so there isn't a disappointing delta between what the title promises and the body delivers. We did that in two ways: by adding Github, and by replacing the "Why" bit with a simple mention of the relationship explored by the article. I'm sure it is possible to come up with something better, i.e. more accurate and neutral, and if anybody suggests better we can change it again. But if a paper is going to play the internet game—which, dismayingly, we're seeing more of, as academics increasingly have to fight for clicks in their own right—then HN is going to play the HN game. Your authors are expert in their domain and the HN community is expert in its. I wouldn't say this change is unfair to the authors. The purpose is to steer the thread toward a substantive discussion of their work, just what any good scientist wants, and away from title nitpicks and complaints, which is boring and no one wants. I can tell you from years of experience that once these complaints start appearing, they continue unless and until the title is edited to bring down the inflammation. We can't fight it, we can only heed it—it's a force of nature. Why would that be? I think it's that people come to HN for relief from the onslaught of bait and manipulation that plagues them on most of the internet. The implicit contract here is that the front page will be a bit calmer, more neutral, more accurate. HN doesn't do that perfectly by any means, but if it's noticeably quieter and more bookish than what is typical elsewhere, that's the main thing. You can call HN users armchair scientists if you like, but I think you'd be surprised by how many working scientists participate in this community, not to mention many who have had scientific careers before moving into industry. They are humble and don't flaunt their credentials, but when something relevant to their work comes up they mention it, and it always surprises me how many there are. It seems a good sign for the health of the community.
mikekchar 7y ago
Of course most of the commits are by a small number of developers: Nobody else cares about the project enough to commit. However, the interesting claim of the paper is that restricted numbers of developers increases code quality. However, having skimmed the paper, I'm not really convinced. I see a lot of posturing and quotations from other literature, but very little in the way of data analysis. I'd be extremely happy to be proven wrong, but I don't think this paper has done the analysis to back up its claims.
Haga 7y ago
Have you ever watched a git graph visualization? Some committees are different, they usually start with a small module which is accepted and starts a whole chain reaction of follow up rewrites and sudden appearance of previously unfinished additions.
Illniyar 7y ago
They provide a lot of references in the article to other research that make similar claims from both proprietary and much larger open source projects. At the very least the "Hero model" seems to be as prevalent outside open source as it is in open source. The purpose of the paper was to test and infer from a larger dataset, which open source provides more easily then proprietary. That being said, it really seems like the research was highly guided by an agenda, and I'm not sure how much one can take from this research.
jondubois 7y ago
>> This study is totally unsurprising and totally non-generalizable to professional teams working on proprietary software. I agree that it's unsurprising but disagree that it's non-generalizable. Companies need to break large projects into small subproject teams and one or two people on those teams need to be deeply involved in the subject matter of the subproject. Also companies tend to treat developers as disposable entities. If you treat your engineers like crap (and don't reward them with company shares), then your company will never be able to keep any 10x engineers. Your company's products will always be mediocre, buggy, slow to develop (you will need a lot. more tests)...
- mruniverse 7y ago
  The "disposable entities" part reminds me of sprints where everything is broken down into 2-3 week chunks. A deliverable is expected in that time. It can be a tiny part or bigger part but must be a complete "thing" with unit tests and what not. It tracks with the idea that programming is like factory work.

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!
  - gmolau 7y ago
    Not trying to start an argument over words, but that seems a bit unfair to the authors. Their title promised they would analyze 1100 projects, and that is what they did. Being accused of misleading or even linkbaiting their readers by (let's be honest) armchair scientists imho doesn't reflect well on this platform.
    - Illniyar 7y ago
      Just because it's true doesn't mean it isn't misleading. Consider if they had the same title but only analyzed projects with a single contributor or pet projects. By only including open source projects they've limited the ability to generalize their conclusions, which they themselves allude to in their "threats to validity" section. Changing the title simply better reflects the content of the article, which the researchers didn't do (sometimes this is due to external pressures such as university PR departments, but I doubt is the case here)
    - dang 7y ago
      The number of projects analyzed was not the issue, though "1100+" does add to the impression of the title being hotrodded a bit. The criticisms HN users made of the title, that I heard, were first that the paper looks only at open-source projects on Github, which is not representative of software projects in general, while the title refers to software projects in general. Second, "Why X needs Y" (where Y is a sensational word like "heroes") is a linkbait trope, easily recognized by anyone who spends time around internet articles, as well as an overselling of the finding. An analysis of commit rates on Github does not explain why, it shows that—which is great, and which we edited the title to represent more clearly. On HN, an article does not get a pass to use these tricks just because it's a paper on Arxiv. The internet game is to inflate titles to oversell the body, and the HN game is to rejig them back to scale, so there isn't a disappointing delta between what the title promises and the body delivers. We did that in two ways: by adding Github, and by replacing the "Why" bit with a simple mention of the relationship explored by the article. I'm sure it is possible to come up with something better, i.e. more accurate and neutral, and if anybody suggests better we can change it again. But if a paper is going to play the internet game—which, dismayingly, we're seeing more of, as academics increasingly have to fight for clicks in their own right—then HN is going to play the HN game. Your authors are expert in their domain and the HN community is expert in its. I wouldn't say this change is unfair to the authors. The purpose is to steer the thread toward a substantive discussion of their work, just what any good scientist wants, and away from title nitpicks and complaints, which is boring and no one wants. I can tell you from years of experience that once these complaints start appearing, they continue unless and until the title is edited to bring down the inflammation. We can't fight it, we can only heed it—it's a force of nature. Why would that be? I think it's that people come to HN for relief from the onslaught of bait and manipulation that plagues them on most of the internet. The implicit contract here is that the front page will be a bit calmer, more neutral, more accurate. HN doesn't do that perfectly by any means, but if it's noticeably quieter and more bookish than what is typical elsewhere, that's the main thing. You can call HN users armchair scientists if you like, but I think you'd be surprised by how many working scientists participate in this community, not to mention many who have had scientific careers before moving into industry. They are humble and don't flaunt their credentials, but when something relevant to their work comes up they mention it, and it always surprises me how many there are. It seems a good sign for the health of the community.

mikekchar 7y ago

Of course most of the commits are by a small number of developers: Nobody else cares about the project enough to commit. However, the interesting claim of the paper is that restricted numbers of developers increases code quality. However, having skimmed the paper, I'm not really convinced. I see a lot of posturing and quotations from other literature, but very little in the way of data analysis. I'd be extremely happy to be proven wrong, but I don't think this paper has done the analysis to back up its claims.

Haga 7y ago

Have you ever watched a git graph visualization? Some committees are different, they usually start with a small module which is accepted and starts a whole chain reaction of follow up rewrites and sudden appearance of previously unfinished additions.

Illniyar 7y ago

They provide a lot of references in the article to other research that make similar claims from both proprietary and much larger open source projects. At the very least the "Hero model" seems to be as prevalent outside open source as it is in open source. The purpose of the paper was to test and infer from a larger dataset, which open source provides more easily then proprietary. That being said, it really seems like the research was highly guided by an agenda, and I'm not sure how much one can take from this research.

jondubois 7y ago

>> This study is totally unsurprising and totally non-generalizable to professional teams working on proprietary software. I agree that it's unsurprising but disagree that it's non-generalizable. Companies need to break large projects into small subproject teams and one or two people on those teams need to be deeply involved in the subject matter of the subproject. Also companies tend to treat developers as disposable entities. If you treat your engineers like crap (and don't reward them with company shares), then your company will never be able to keep any 10x engineers. Your company's products will always be mediocre, buggy, slow to develop (you will need a lot. more tests)...

mruniverse 7y ago
The "disposable entities" part reminds me of sprints where everything is broken down into 2-3 week chunks. A deliverable is expected in that time. It can be a tiny part or bigger part but must be a complete "thing" with unit tests and what not. It tracks with the idea that programming is like factory work.