Both of those metrics are incredibly shit ways to measure productivity.
I guess thats one explanation as to why the facebook app is 200mb+. They've been superproductive with all those lines of code.
A better metric would rely on actual features or bugs, imo.
Also, there is a difference between using them as metrics that you want to raise vs metrics you just don't want to drop or fluctuate wildly over time.
Why even bother measuring lines of code/number of commits.
Presumably your consulting business has really taken off now that you have such unique insight into a historically unempirical area of our field?
See also: https://users.cs.duke.edu/~ola/courses/cps108/code/java/harp...
Throughout my career imve found that number of changes comitted correlates pretty well with features delivered and bugs fixed. Also with feature and bug size.
Yes there are edge cases when it takes a day of debugging to make a 1-line fix, but those are rare. Just like it’s very rare to deliver a useful new feature by changing a single line.
Yes there are also features that are tracked as a real ticket and require a 1-line copy change and nothing else. Nobody thinks doing those makes you hella productive, it just needs to be done.
As for padding lines and changes. That’s what code review is for.
One should, but companies often care more about effort than results. They can manage based on effort, they can't manage based on results.
If you spend 2 days getting the same results as somebody else does in 5 days, guess what, they don't want you milling around those extra 3 days and bringing morale down. Gotta give you more work!
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
That said, one of my favorite metrics is number of deleted LOC.
This is 'productivity' in the sense of the release eng team attempting to measure the volume of code changes they're pushing out and whether changes they made to the push/release process impacted other teams' ability to iterate. Unless you have some insight as to why adopting a more continuous deployment process would change the ratio between LOC pushed or code-changing-diffs pushed to features-or-bugs specifically at Facebook such that they would not function as acceptable proxies, questioning the metric chosen seems hollow. It's certainly not 'productivity' in the sense of whether people on product teams are considered to have done a good job or are deserving of bonuses / promotions.
If the build system is super slow and just breaks all the time, your going to see a drop in the number of commits landed per day. If git is completely down and commits per day drop per 0, then you have an outage ;)
BUT, if a team of developers is not padding their code, nor has shitty programmers who write page after page of nonsense, then in the end the proportion of functionality to LOC should be fairly stable, and thus LOC is a useful and meaningful proxy metric for the amount of new or changed functionality in a codebase.
Its not difficult to track "velocity" via story points,features or bugs and is at least a step in the right direction.
LOC going down is often adding the most value.
People also take offense because a management weenie can misread the metric and penalize people who delete code, or write concise code, or solved a super tricky critical bug after a month of debugging with a one-line change.
But I still claim, these all normalize in the end. If a developer on my team has committed only 30 lines in three months, sorry but I'm gonna be skeptical of their actual productivity.
No, but you can implement a "story", i.e. the removal of code is presumably a ticket somewhere in the system. (Or could become one.)
> I've never been in a codebase that did more and more by getting smaller.
Run on a smaller system? Run faster?
(I'm not sure whether or not I agree with the parent's point, nor yours, just offering suggestions.)
If LOC is what you rely on, I'd be sceptical of many things, sorry not sorry.
I've just committed 3 lines that fix a bad intermittent race condition that took over a month to track down (partially because I can't test it and have to rely on other people who aren't 100% available). Is that unproductive?
On the other end, I'd fully expect someone doing that producing : - 3 lines of fix - A comprehensive documentation of what happened here, how to diagnose it and track it down, and how to avoid it in the future, (ideally if the company supports it with an oral explanation to concerned teammates).
In the end, I'd be very skeptical of one month of work letting 3 LOC as the only tangible output too.
The problem and diagnostic conversations are documented in the JIRA ticket; the solution is documented in another ticket which "fixes" the first one (for abstruse internal reasons); and more commentary is provided in both the comments around my fix and my verbose commit message.
(Also there's a whole bunch of angry Slack ranting about this issue but that probably doesn't count as "documentation".)
I suppose it depends what people mean by LOC. I guess my 3 LOC isn't actually just those 3 LOC. Definitely an interesting thing to think about at least. Ta!
In theory yes. In practice, when you know your team and their average output and quality, no.
>I guess thats one explanation as to why the facebook app is 200mb+. They've been superproductive with all those lines of code
Or you know, most of it is assets, debugging symbols, stray frameworks and libs not stripped, etc. As is the case with almost any app beyond a few MB.
LOC or commits are certainly bad ways of comparing two different people, teams, etc. But they are fine ways of measuring whether a specific event at a specific time changed productivity, assuming a decently large team etc.