4 ms·

LOC is far, far from a perfect measure of productivity, but ultimately if you do want to be shipping plenty of customer value (and/or tech debt reduction), it d

by yashap 3y ago

LOC is far, far from a perfect measure of productivity, but ultimately if you do want to be shipping plenty of customer value (and/or tech debt reduction), it does take plenty of code to do so. Sometimes there’s 10 LOC which huge value, but if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow. I also think that this: > There's a level of mature projects where you don't really do new features anymore. Is fine for a product that’s basically “done”, but who’s paying you to work on those? More common is that the product would benefit a lot from improvements, but the company/dev team has basically lost so much velocity that they can no longer ship them.

aaomidi 3y ago
For example, I work in a CA. There's really not much code to write other than keeping up with new standards and requirements.
- yashap 3y ago
  Yeah, at a CA, fair enough. But there are tonnes of B2B or B2C SaaS type products, that do need new features, bug fixes, performance improvements, UX improvements, etc., but aren’t getting them quickly because dev productivity has declined so far. Typically environments with confusing architecture, slow local dev flow, slow CI, poor test coverage and tonnes of manual QA required, etc.
viraptor 3y ago
> Is fine for a product that’s basically “done”, but who’s paying you to work on those? Most companies that are actually profitable. There's a massive amount of space in between "done" and startup level expansion. There are good, mature projects which need some improvements and TLC, without expanding their scope every day. And because they're already large and most of the simple issues have been addressed, you start getting the interesting problems that take many more times as long to investigate and understand as they take to fix.
- yashap 3y ago
  Eh, a lot of the biggest, most successful/profitable tech companies are still rapidly developing new products, features, etc. For example, Google, Amazon and Apple are all still innovating pretty fast. Lots of others have basically stopped shipping new products, new features, performance improvements, UX improvements, etc. But I think that’s frequently an undesirable state the company has gotten into, they’d love to be productive but have lost the ability.
  - viraptor 3y ago
    > For example, Google, Amazon and Apple are all still innovating pretty fast. I'd dispute that in general. And definitely if you mean amount of innovation per employee. They try random new things that either lives in its little corner, or gets killed in a couple of years. They sure have lots of churn and likely lots of lines of code flying around, but innovation...? There's two projects from Apple from the last decade that I'd call innovation. Amazon marketplace is static and AWS just gains new features that are mostly expected / business as usual. Google kills as much as it creates all the time. I really don't think those are great examples of moving fast.
  - civilized 3y ago
    The idea that constantly making new stuff is what makes you great is a developer-centric ideology. With products from a mature company like Google, customers mostly just want the existing stuff to work.
deleted 3y ago
[deleted]
usea 3y ago
> ultimately if you do want to be shipping plenty of customer value (and/or tech debt reduction), it does take plenty of code to do so. You can add features / value by only removing code.
- kqr 3y ago
  Sure you can. Consistently over a meaningful time span like a year, though?
chongli 3y ago
Whenever anyone talks about lines of code as a productivity measure, I’m reminded of this story about Bill Atkinson (arguably the most brilliant developer on the original Macintosh and Lisa teams) [1]. Just to note, this event occurred years before the Macintosh released, when the code was far from mature. [1] https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- cdchn 3y ago
  The developer who is removing more lines of code is frequently producing greater value than those who are adding them.
- BillyTheKing 3y ago
  He basically re-wrote the whole software though.. which is not -2k lines of code, but + probably a few hundred a week if not more
cdchn 3y ago
LOC is so divorced from measures of productivity no rational shop actually uses it as a measure of productivity/value.
vidarh 3y ago
> Sometimes there’s 10 LOC which huge value, but if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow. To me this belief is a big red flag. The most productive developers I've worked with have all been among those on the team with the lowest LOC count. Writing lots of code is easy: Ignore good practices, don't think through how to generalize components, and reducing boilerplate, and in the process of doing so create a codebase where getting anything done without high LOC changes becomes progressively harder. In my last job, I spent many weeks on a component that ended up at ~2KLOC. In the same time period, we had several people writing thousands of lines of code each of views and controllers for a number of database tables. Once my component was done, it dynamically synthesized the starting point for 10x the number of tables let us cut weeks of developer time off the work involved for each model where we now just had to fill in some config and write the occasional custom component to make things nicer. It also let me spend the following week deleting many thousands of LOC of code the rest of the team had written that had been rendered entirely redundant, so my average LOC produced for that period was net negative and cut months off our delivery timeline. Sustained high LOC count is to me a warning sign. If the code is easy enough to write that you can churn it out at high tempo, odds are there are patterns that can be generalised and wrapped up in higher-leverage components that you're ignoring.
- nerdponx 3y ago
  You're talking about LOC per feature or project. GP is talking about LOC averaged over the whole organization, over all features and projects. I actually think you're both right.
  - vidarh 3y ago
    I specifically talked about this quote from them: > if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow. And that is what I took issue with. It's specifically talking specifically about the most productive devs, and about shipping code. I was not talking about per feature or per project. I was talking in general.
- 3y ago

by yashap 3y ago

aaomidi 3y ago

For example, I work in a CA. There's really not much code to write other than keeping up with new standards and requirements.

yashap 3y ago
Yeah, at a CA, fair enough. But there are tonnes of B2B or B2C SaaS type products, that do need new features, bug fixes, performance improvements, UX improvements, etc., but aren’t getting them quickly because dev productivity has declined so far. Typically environments with confusing architecture, slow local dev flow, slow CI, poor test coverage and tonnes of manual QA required, etc.

viraptor 3y ago

> Is fine for a product that’s basically “done”, but who’s paying you to work on those? Most companies that are actually profitable. There's a massive amount of space in between "done" and startup level expansion. There are good, mature projects which need some improvements and TLC, without expanding their scope every day. And because they're already large and most of the simple issues have been addressed, you start getting the interesting problems that take many more times as long to investigate and understand as they take to fix.

yashap 3y ago
Eh, a lot of the biggest, most successful/profitable tech companies are still rapidly developing new products, features, etc. For example, Google, Amazon and Apple are all still innovating pretty fast. Lots of others have basically stopped shipping new products, new features, performance improvements, UX improvements, etc. But I think that’s frequently an undesirable state the company has gotten into, they’d love to be productive but have lost the ability.
- viraptor 3y ago
  > For example, Google, Amazon and Apple are all still innovating pretty fast. I'd dispute that in general. And definitely if you mean amount of innovation per employee. They try random new things that either lives in its little corner, or gets killed in a couple of years. They sure have lots of churn and likely lots of lines of code flying around, but innovation...? There's two projects from Apple from the last decade that I'd call innovation. Amazon marketplace is static and AWS just gains new features that are mostly expected / business as usual. Google kills as much as it creates all the time. I really don't think those are great examples of moving fast.
- civilized 3y ago
  The idea that constantly making new stuff is what makes you great is a developer-centric ideology. With products from a mature company like Google, customers mostly just want the existing stuff to work.

deleted 3y ago

[deleted]

usea 3y ago

> ultimately if you do want to be shipping plenty of customer value (and/or tech debt reduction), it does take plenty of code to do so. You can add features / value by only removing code.

kqr 3y ago
Sure you can. Consistently over a meaningful time span like a year, though?

chongli 3y ago

Whenever anyone talks about lines of code as a productivity measure, I’m reminded of this story about Bill Atkinson (arguably the most brilliant developer on the original Macintosh and Lisa teams) [1]. Just to note, this event occurred years before the Macintosh released, when the code was far from mature. [1] https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

cdchn 3y ago
The developer who is removing more lines of code is frequently producing greater value than those who are adding them.
BillyTheKing 3y ago
He basically re-wrote the whole software though.. which is not -2k lines of code, but + probably a few hundred a week if not more

cdchn 3y ago

LOC is so divorced from measures of productivity no rational shop actually uses it as a measure of productivity/value.

vidarh 3y ago

> Sometimes there’s 10 LOC which huge value, but if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow. To me this belief is a big red flag. The most productive developers I've worked with have all been among those on the team with the lowest LOC count. Writing lots of code is easy: Ignore good practices, don't think through how to generalize components, and reducing boilerplate, and in the process of doing so create a codebase where getting anything done without high LOC changes becomes progressively harder. In my last job, I spent many weeks on a component that ended up at ~2KLOC. In the same time period, we had several people writing thousands of lines of code each of views and controllers for a number of database tables. Once my component was done, it dynamically synthesized the starting point for 10x the number of tables let us cut weeks of developer time off the work involved for each model where we now just had to fill in some config and write the occasional custom component to make things nicer. It also let me spend the following week deleting many thousands of LOC of code the rest of the team had written that had been rendered entirely redundant, so my average LOC produced for that period was net negative and cut months off our delivery timeline. Sustained high LOC count is to me a warning sign. If the code is easy enough to write that you can churn it out at high tempo, odds are there are patterns that can be generalised and wrapped up in higher-leverage components that you're ignoring.

nerdponx 3y ago
You're talking about LOC per feature or project. GP is talking about LOC averaged over the whole organization, over all features and projects. I actually think you're both right.
- vidarh 3y ago
  I specifically talked about this quote from them: > if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow. And that is what I took issue with. It's specifically talking specifically about the most productive devs, and about shipping code. I was not talking about per feature or per project. I was talking in general.
3y ago