It's true that torturing a person is an effective way to change what that person wants. It doesn't always end with the torturer getting what they want, though.
I think it's obvious that they're bad at a small scale (individually or for smallish teams, maybe < 30 engineers?), but I don't think they're _obviously_ bad for teams of 50+ engineers.
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.
Some people at Google are actually quite proud of six digit _negative_ line counts they've contributed. And I think they have every right to be proud of that.
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.
That would be a bad metric for those "negative" folks as well. Their job is called "code cultivation", and they modify everything in Google's monorepo to make it suck less. Often this is done using automated tools, with a subsequent full run of affected tests and human code review. I've never seen anything like this anywhere else, and I probably won't for the rest of my career.
As to what one should track, one should track _results_ if you've managed to accomplish something useful with very little code, that is decidedly better than accomplishing the same with much more code and hundreds of check-ins. Simplicity is the ultimate sophistication.
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!
And worse: in more than one megacorp (including Google in late aughts) I've seen _complexity_ as a requirement for promotion. Google has tried to get rid of that de jure, but it remains a requirement in practice, so people do what they are rewarded for: create complexity.
Well at that point I think you've hit the agency problem where management's goals and the organization's goals are different. The organization's goal is delivering results but that is not necessarily what management wants right now.
You're arguing against an extreme, though. Sure, if LOC added (or even just changed, which is the saner metric) was linked directly to bonuses, it'd be ripe for abuse. But that completely ignores the more reasonable use in the article, as one (of several) metrics used to measure the impact of their release process.
Literally the next sentence: """Similarly, the number of critical issues arising from mobile releases is almost constant regardless of the number of deployments, indicating that our code quality does not suffer as we continue to scale."""
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.
I think what they are trying to measure is how much is this build/release system effecting productivity of the engineers and changes their behavior. Not how productive the engineers are per say.
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 ;)
Some people, perhaps you as well, take offense at LOC metrics because they're (in theory) easy to game, via redundant code, whitespace, verbose vs concise languages, etc. And because good developers know that small code and systems mean fewer opportunities for lurking bugs and points of failure.
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.
Sure, deleting unused or bad code is a good thing, or refactoring or rewriting something more tightly. But you can't implement a new feature just by deleting code. I've never been in a codebase that did more and more by getting smaller.
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.
> 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.
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.
> A comprehensive documentation of what happened here, how to diagnose it and track it down, and how to avoid it in the future
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 never meant to say you did a bad job (looks like you certainly did a great one !), but just that a month of work typically leaves in the end, for good reasons, more than 3 LOC in "committed" (in the sense of accessible to the company as an asset in the long term) work, which was apparently the case for you too !
> leaves in the end, for good reasons, more than 3 LOC in "committed" work
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!
That assumes there's sufficiently small chunks of work in the sprint (we're not allowed to touch anything out-of-sprint) to fit into the gaps whilst I'm waiting.
You may want to push back on that. I understand the reasoning but anytime upper management tells people not to work on stuff there is usually a communication breakdown some where.
> Both of those metrics are incredibly shit ways to measure productivity.
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.
Sure, nobody should setup incentives based on LOC. But in this case it's not about incentives, it just about seeing if something changed. Nobody writing code is going to be rewarded or penalized if this number changes.
That's not really relevant; if they knew they were being measured before and after the change, it would still show if the new system had an impact on productivity - even faked.
I'd guess LoC changed is implicit in "lines of code pushed", which is a blunt measurement, but isn't the same as the traditional LOC metric and doesn't directly correlate to (rewarding) a large download.
Better in which way? In your daily usage scenario? Memory usage?
I'm sure there will be cases where Vim or notepad++ works better for me. At present, vscode works for 90%+ of the things I need to do.
For my usage scenario, notepad++ is not better than vscode. Use whatever application works for you, but don't say something is better or worse, without looking at it subjectively.
For a person who is relying on benchmarks, you should know that benchmarks are only a rough indication of how well anything performs for a very specific use case.
Your reply is arrogant and ignorant, and you should feel bad about typing that.
> If you are that interested do your own tests.
Why is he not allowed to review your results or check what factors you benchmarked it on?
If there's no citation, that claim does not stand.
To be fair, Oracle is usually extremely good at most of the stuff it does. I've no idea about GIS specifically, but, generally, you get what you pay for.
