5 ms·

I've always wondered if the productivity metric chosen could adversely affect the code quality. I think this answers that well. The more LOC you have the higher

I've always wondered if the productivity metric chosen could adversely affect the code quality. I think this answers that well. The more LOC you have the higher technical debt you will have and thus to have LOC or scrum points as a metric is basically encouraging technical debt.

sharemywin 9y ago
scrum points are different then lines of code. scrum points are based on the complexity of the problem and LOC is based on how inefficiently you can code a problem.
- tedmiston 9y ago
  ^ I agree with this. My main point is that LoC is always a bad metric. Scrum points can be a bad metric if misused for purposes other than estimating the effort required to solve a given problem.
matt_s 9y ago
One thing to consider is if the programmer "owns" the code through deployment into production. If that is the case then the focus is working software not LOC or story points or velocity or tickets closed. It's much better to have a flow that allows for continuous delivery of working software with monitoring, etc. rather than focusing on counts of things that don't matter. Do customers care about how many story points happened last sprint? If management is focusing more on metrics than working software - then they will get people to focus on that as well over working software.
WrtCdEvrydy 9y ago
I used to track "time in production" along with "lines written". It was really interesting to weigh "time in production" for lines of code to see how rushing to get more lines in ended in us rewriting more and more of a developer's code.
- flukus 9y ago
  How much of the long serving lines are bit's that no one wants to touch anymore and are constantly worked around? Sometimes those lines will have enough technical debt attached that the business will not even consider updating/extending those parts of an application.
  - WrtCdEvrydy 9y ago
    Those are what we call 'core components' and they are never 'rewritten'. Because it's cheaper to throw more cloud RAM at it than to rewrite it.
flukus 9y ago
> The more LOC you have the higher technical debt you will have and thus to have LOC or scrum points as a metric is basically encouraging technical debt. There's a correlation, but it's more subtle than that. Often simpler but repetitive code is less technical debt than the less code but more complicated version.
- aaronarduino 9y ago
  The more complicated and harder to understand the code the longer it takes to change/fix/refactor leading to wasted time.

sharemywin 9y ago

scrum points are different then lines of code. scrum points are based on the complexity of the problem and LOC is based on how inefficiently you can code a problem.

tedmiston 9y ago
^ I agree with this. My main point is that LoC is always a bad metric. Scrum points can be a bad metric if misused for purposes other than estimating the effort required to solve a given problem.

matt_s 9y ago

One thing to consider is if the programmer "owns" the code through deployment into production. If that is the case then the focus is working software not LOC or story points or velocity or tickets closed. It's much better to have a flow that allows for continuous delivery of working software with monitoring, etc. rather than focusing on counts of things that don't matter. Do customers care about how many story points happened last sprint? If management is focusing more on metrics than working software - then they will get people to focus on that as well over working software.

WrtCdEvrydy 9y ago

I used to track "time in production" along with "lines written". It was really interesting to weigh "time in production" for lines of code to see how rushing to get more lines in ended in us rewriting more and more of a developer's code.

flukus 9y ago
How much of the long serving lines are bit's that no one wants to touch anymore and are constantly worked around? Sometimes those lines will have enough technical debt attached that the business will not even consider updating/extending those parts of an application.
- WrtCdEvrydy 9y ago
  Those are what we call 'core components' and they are never 'rewritten'. Because it's cheaper to throw more cloud RAM at it than to rewrite it.

flukus 9y ago

> The more LOC you have the higher technical debt you will have and thus to have LOC or scrum points as a metric is basically encouraging technical debt. There's a correlation, but it's more subtle than that. Often simpler but repetitive code is less technical debt than the less code but more complicated version.

aaronarduino 9y ago
The more complicated and harder to understand the code the longer it takes to change/fix/refactor leading to wasted time.