8 ms·

Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC c

by lakpan 2y ago

Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.

xandrius 2y ago
Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
- khazhoux 2y ago
  > Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
  - mdp2021 2y ago
    That makes your point clear, but then what you are looking for is not a scalar value (that may be for instance be subject to a proportional judgement) but a fuzzy threshold.
  - eviks 2y ago
    Might that hint that the problem that is there is that the metric is bad?
    - khazhoux 2y ago
      So if you managed a team, and when you look at commit histories you notice that one person has <1 commit a month and you look at the commits and they're trivial... you would disregard any concerns?
      - jen20 2y ago
        I would wonder how it got to the second month, certainly - getting to the point where this kind of post-hoc analysis can actually be done is a serious failing of management.
      - xandrius 2y ago
        The answer is still "it depends", I would imagine that issues would arise well before you had to look at their commit history. I believe that if you are a good manager, you would just need to look at what tickets get done during the sprint and that's it. If you complete your tickets and pass QA/UAT in 10 LOC, so be it. There is no need to micromanage.
  - Moru 2y ago
    This is exactly why KLoC is not a good measurement. If you know about this, you will make sure you match everyone else by embellishing your line count with comments, copy and rename functions or extra deep nesting. The manager will still not know anything without looking at everyones code.
    - khazhoux 2y ago
      A good manager should look at everyone's code. A good manager should recognize that if a developer does nothing but annotate code with comments, and that's not what they're expected to be doing, there's a problem.
      - Moru 2y ago
        Ofcourse, but if the manager is using the KLoC to decide who to look at, that won't happen.
  - rsynnott 2y ago
    I mean, seems highly role-dependent. If, in practice, your role is to investigate and fix very difficult problems, that’s precisely the sort of commit history one might expect.
khazhoux 2y ago
Right. One data point among many. And managers should be looking at everyone’s code, not just the low LOC ones. But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.
- eviks 2y ago
  confirmation bias indeed works that way more often than not: it confirms what you already believe
  - khazhoux 2y ago
    I'm confused which part of this is so off-putting. Joe is always the one in every standup saying the thing he's working isn't done yet because he's wrestling "one last tough bug." As a manager, you wonder if the technical problems are really that tough or if Joe is just struggling. Let's look at the commit history... yeah, something is off here, Joe has 1/10th the commits of his peers and they really don't seem more complex in any way, but look rather trivial. Time to talk to Joe and look at these commits together and see what's going on. Is that really such a troubling proposition?
    - eviks 2y ago
      So troubling that you can't propose it cleanly: if you've already defined that "they really don't seem more complex in any way, but look rather trivial", why would you need to count? (another troubling sign is going for the order of magnitude assessments, and another minor point: you've mistakenly replaced volume of code with # of commits)
    - jen20 2y ago
      So why wasn’t the response after day 1 of the “tough bug” something like “hey, why don’t you pair with X to get to the bottom of it?”?
supriyo-biswas 2y ago
I wonder what the grandparent would think about a few LOC/month, there were a few rather gnarly performance issues in the codebase at my work for which the fix was usually a one or two liner, but that took an inordinate amount of research to even know where to start looking. I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.
- khazhoux 2y ago
  Yes, but I'm guessing your commit history over the last year is not just 1/2-liners once a month, right?

by lakpan 2y ago

Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.

xandrius 2y ago

Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)

khazhoux 2y ago
> Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
- mdp2021 2y ago
  That makes your point clear, but then what you are looking for is not a scalar value (that may be for instance be subject to a proportional judgement) but a fuzzy threshold.
- eviks 2y ago
  Might that hint that the problem that is there is that the metric is bad?
  - khazhoux 2y ago
    So if you managed a team, and when you look at commit histories you notice that one person has <1 commit a month and you look at the commits and they're trivial... you would disregard any concerns?
    - jen20 2y ago
      I would wonder how it got to the second month, certainly - getting to the point where this kind of post-hoc analysis can actually be done is a serious failing of management.
    - xandrius 2y ago
      The answer is still "it depends", I would imagine that issues would arise well before you had to look at their commit history. I believe that if you are a good manager, you would just need to look at what tickets get done during the sprint and that's it. If you complete your tickets and pass QA/UAT in 10 LOC, so be it. There is no need to micromanage.
- Moru 2y ago
  This is exactly why KLoC is not a good measurement. If you know about this, you will make sure you match everyone else by embellishing your line count with comments, copy and rename functions or extra deep nesting. The manager will still not know anything without looking at everyones code.
  - khazhoux 2y ago
    A good manager should look at everyone's code. A good manager should recognize that if a developer does nothing but annotate code with comments, and that's not what they're expected to be doing, there's a problem.
    - Moru 2y ago
      Ofcourse, but if the manager is using the KLoC to decide who to look at, that won't happen.
- rsynnott 2y ago
  I mean, seems highly role-dependent. If, in practice, your role is to investigate and fix very difficult problems, that’s precisely the sort of commit history one might expect.

khazhoux 2y ago

Right. One data point among many. And managers should be looking at everyone’s code, not just the low LOC ones. But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.

eviks 2y ago
confirmation bias indeed works that way more often than not: it confirms what you already believe
- khazhoux 2y ago
  I'm confused which part of this is so off-putting. Joe is always the one in every standup saying the thing he's working isn't done yet because he's wrestling "one last tough bug." As a manager, you wonder if the technical problems are really that tough or if Joe is just struggling. Let's look at the commit history... yeah, something is off here, Joe has 1/10th the commits of his peers and they really don't seem more complex in any way, but look rather trivial. Time to talk to Joe and look at these commits together and see what's going on. Is that really such a troubling proposition?
  - eviks 2y ago
    So troubling that you can't propose it cleanly: if you've already defined that "they really don't seem more complex in any way, but look rather trivial", why would you need to count? (another troubling sign is going for the order of magnitude assessments, and another minor point: you've mistakenly replaced volume of code with # of commits)
  - jen20 2y ago
    So why wasn’t the response after day 1 of the “tough bug” something like “hey, why don’t you pair with X to get to the bottom of it?”?

supriyo-biswas 2y ago

I wonder what the grandparent would think about a few LOC/month, there were a few rather gnarly performance issues in the codebase at my work for which the fix was usually a one or two liner, but that took an inordinate amount of research to even know where to start looking. I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.

khazhoux 2y ago
Yes, but I'm guessing your commit history over the last year is not just 1/2-liners once a month, right?