News for hackers. Stuff that matters.

A comment on Why Google Stores Billions of Lines of Code in a Single Repository (2016). Parent comment

Re:Why Google Stores Billions of Lines of Code in a Single R... by joshuamorton on Saturday January 11, 2020 @05:40PM (#22022886)
I don't think the research is public, because it's all entirely about internal tools, but yes the conclusion was that the got interface for perforce led to less efficient development across basically any metric you could look at (LoC, commit count, self-reported efficacy, etc.). Note that if you judge developers based on commit count is a bad metric, but comparing LoC throughout of developers who are evaluated on other metrics isn't problematic.
[ Parent | on HN ]
Re:Why Google Stores Billions of Lines of Code in a Single R... by rak00n on Sunday January 12, 2020 @02:25AM (#22025016)
I just searched in moma with variations of “git5 productivity” and no such study showed up. Neither LoC nor commit count is a good metric to represent a developer’s productivity.

In my personal opinion, using a git/hg like interface makes it lot easier to work on a complicated CL because you can maintain internal local branches and you can easily revert your incremental changes. That’s not at all possible in perforce. I just can’t see how git/hg interface can make anyone less productive.

[ Parent | on HN ]
Re:Why Google Stores Billions of Lines of Code in a Single R... by joshuamorton on Sunday January 12, 2020 @02:42AM (#22025061)
> Neither LoC nor commit count is a good metric to represent a developer’s productivity.

They're not a good metric to judge a developer on. But when you can do a large controlled study (or even before/after with the same developer), without the developer knowing they're being watched, it's a good metric.

[ Parent | on HN ]