4 ms·

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 fo

by Osmose 9y ago

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.

nimchimpsky 9y ago
I just think they are bad for anyone. Its not hard to measure actual useful things like features or bug. Why even bother measuring lines of code/number of commits.
- dikaiosune 9y ago
  > Its not hard to measure actual useful things like features or bug. Presumably your consulting business has really taken off now that you have such unique insight into a historically unempirical area of our field?
- richardwhiuk 9y ago
  Measuring bugs and features leads to other equally horrendous problematic behaviors.
ktRolster 9y ago
If you use "number of lines of code" as a metric for productivity, soon people will double-space their code. We went through that in the 90s.
- khazhou 9y ago
  Were there any other signs you had shitty programmers on your team?
  - ktRolster 9y ago
    It's not about shitty or good, it's about management. Whatever you reward, that's what people will give you. See also: https://users.cs.duke.edu/~ola/courses/cps108/code/java/harpoon/images/dilbert/bug.gif https://users.cs.duke.edu/~ola/courses/cps108/code/java/harp...
    - Osmose 9y ago
      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.
      - deleted 9y ago
        [deleted]
      - ktRolster 9y ago
        You should measure what you want more of. Unless for some reason you want more lines of code, then use a different metric.
      - gardnr 9y ago
        They should measure and reward lines of code removed instead.
  - testvox 9y ago
    Measuring productivity in LOC...
0xbear 9y ago
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.
- Swizec 9y ago
  That’s why you track changes made. 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.
  - 0xbear 9y ago
    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.
  - 0xbear 9y ago
    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.
    - Swizec 9y ago
      > one should track _results_ 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!

by Osmose 9y ago

nimchimpsky 9y ago

I just think they are bad for anyone. Its not hard to measure actual useful things like features or bug. Why even bother measuring lines of code/number of commits.

dikaiosune 9y ago
> Its not hard to measure actual useful things like features or bug. Presumably your consulting business has really taken off now that you have such unique insight into a historically unempirical area of our field?
richardwhiuk 9y ago
Measuring bugs and features leads to other equally horrendous problematic behaviors.

ktRolster 9y ago

If you use "number of lines of code" as a metric for productivity, soon people will double-space their code. We went through that in the 90s.

khazhou 9y ago
Were there any other signs you had shitty programmers on your team?
- ktRolster 9y ago
  It's not about shitty or good, it's about management. Whatever you reward, that's what people will give you. See also: https://users.cs.duke.edu/~ola/courses/cps108/code/java/harpoon/images/dilbert/bug.gif https://users.cs.duke.edu/~ola/courses/cps108/code/java/harp...
  - Osmose 9y ago
    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.
    - deleted 9y ago
      [deleted]
    - ktRolster 9y ago
      You should measure what you want more of. Unless for some reason you want more lines of code, then use a different metric.
    - gardnr 9y ago
      They should measure and reward lines of code removed instead.
- testvox 9y ago
  Measuring productivity in LOC...

0xbear 9y ago

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.

Swizec 9y ago
That’s why you track changes made. 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.
- 0xbear 9y ago
  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.
- 0xbear 9y ago
  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.
  - Swizec 9y ago
    > one should track _results_ 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!