4 ms·

I'm not offended I just think its shit. Its not difficult to track "velocity" via story points,features or bugs and is at least a step in the right direction.

I'm not offended I just think its shit. 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.

khazhou 9y ago
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.
- lomnakkus 9y ago
  > But you can't implement a new feature just by deleting code. 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.)
  - deleted 9y ago
    [deleted]
- nimchimpsky 9y ago
  > 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 LOC is what you rely on, I'd be sceptical of many things, sorry not sorry.
- zimpenfish 9y ago
  > 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?
  - C4stor 9y ago
    It's not. 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.
    - zimpenfish 9y ago
      > 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".)
      - C4stor 9y ago
        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 !
        zimpenfish 9y ago
        > 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!
vacri 9y ago
Story points vary wildly between teams. I'd argue that they're a worse metric than LOC

khazhou 9y ago

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.

lomnakkus 9y ago
> But you can't implement a new feature just by deleting code. 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.)
- deleted 9y ago
  [deleted]
nimchimpsky 9y ago
> 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 LOC is what you rely on, I'd be sceptical of many things, sorry not sorry.
zimpenfish 9y ago
> 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?
- C4stor 9y ago
  It's not. 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.
  - zimpenfish 9y ago
    > 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".)
    - C4stor 9y ago
      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 !
      - zimpenfish 9y ago
        > 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!

vacri 9y ago

Story points vary wildly between teams. I'd argue that they're a worse metric than LOC