6 ms·

Not the core point of the article, but … > To be clear, at a steady state in a mature project, I get something like 125 lines of code into production per week.

by yashap 3y ago

Not the core point of the article, but … > To be clear, at a steady state in a mature project, I get something like 125 lines of code into production per week. I don’t think this is uncommon, but it’s wild to me that so many companies let their dev productivity degrade to this level. I work at a decent sized startup, 8 years old, fairly large codebase, and even junior devs who are pretty new to the company are averaging a couple hundred LOC/week shipped to prod, while the most productive devs are averaging ~1K LOC/week. We spend plenty of time keeping the dev env fast, keeping CI (build, test and deploy) fast, minimizing risk even with minimal QA (strong test coverage, canary deploys with auto-rollback, strong alerting), and refactoring to reduce complexity. But even still, ~60% of overall dev time is spent on product stuff, and this other ~40% is SO worth it if it keeps devs ~10x as productive. An environment where even strong devs only average ~125 LOC/week is just so, so unproductive, it’s crazy to me that companies let this become the norm. Prior to my current company (which I would consider very high productivity), I worked at a place where the productivity was more inline with 125 LOC/week (experienced, fully on-boarded devs were around 200 I’d guess), I can see how this happens, but it’s crazy to me that so many companies LET it happen.

lovich 3y ago
That was a reference per project, how many engineers have only a single project they maintain? I’ve had between 5-160(way too many to realistically maintain) at every point in my career but it never got to 1. I think the lowest was 3 for a month period inbetween sunsetting one project as the contract had ended and then getting assigned a new project because I had the spare capacity
viraptor 3y ago
There's a level of mature projects where you don't really do new features anymore. There's polish and some changes and focusing on more reliability instead. And in those cases, you need lots more testing and validation and not much stupid code. I had one leg in development and one in operations and had weeks where I merged 10 lines of change - and they were properly tested and important 10 lines and that was how long they needed take. LOC is a silly metric - don't let it become your dick measuring contest or expect it to correlate with level and you'll learn to appreciate the small, difficult changes too. (the lower my LOC got, the longer my documentation, diagrams and project proposals got)
- 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.
kqr 3y ago
Author here. This is a topic that fascinates me to no end, and I have a million questions for you that are off-topic here. Do you mind sending me an email to a@xkqr.org so I can reply with the things I'm curious about? (Anyone who wants to discuss it can send me an email and I'll try to hook everyone up to the same email thread.)
- yashap 3y ago
  Will do!
rconti 3y ago
To be clear, I'm not a programmer, but... Wouldn't you expect LOC shipped to go down as level of impact (eg, size of customer base) goes up? 100 lines on GMail has a lot more impact than 100 lines on a homegrown accounts receivable engine for a small business. Feels like it should be (LOC * weekly_executions) at least. And that's before we get into the efficiency of the code.
yayitswei 3y ago
What language are you using?
cdchn 3y ago
Code is a liability. More code != moar better.
vidarh 3y ago
It's easy to spew out 1K LOC/week of low effort code for simple projects. It takes far more skill to produce 125 lines of high-quality code in a complex one. My most productive recent change had a negative LOC count, and will have a big impact. It's entirely impossible to make an assessment of whether or not 125 lines is good or bad in this instance without knowing more about the type of project etc., but that it is a mature project is already a strong indicator the number quite possibly should be fairly low.
postexitus 3y ago
So, assuming that's a growing startup, if all engineers keep committing 0.5/1k LOC/w with number of engineers doubling every year, what will your codebase grow to in 5 years' time? Let's say you have 20 engineers now (low for 8 year old startup). That's 1M LOC/annum. Next year you add another 2M. Where does this go?
kaba0 3y ago
Writing the same CRUD component for the n+1th page, that is not at all fundamentally different than all the rest, is very different than, say, a compiler/render engine, etc. There are days when my only contribution is a single, slightly modified line of code.
baryphonic 3y ago
I had a similar reaction. If I'm healthy, I can routinely ship 1-2k LOC per week. I sort of regret that at times, because I think we could be just as productive (in terms of useful product) with many fewer LOC, but we are stuck with the constraints we live in. OTOH, I've worked (incredibly frustrating) jobs where the infrastructure is dysfunctional such that the write-compile-test cycles are on the order of tens of minutes, and these have made my LOC/week plummet. In those cases, I've recommended to management that we fix the infrastructure to get down to sub-minute cycles (ideally a few seconds), but usually these have been shot down due to their extreme myopia.
gosub100 3y ago
Many mid-large size companies have meetings, code reviews, paperwork, sprint planning that take up most of the workweek. really depends on the domain. If your team is developing a medical device, no way in hell should you push 1k LoC/week. maybe 1k Lo Documentation. My guess is the 125 LoC/week is a maintenance coder role.
hliyan 3y ago
The most I've ever done was nearly 500 lines of C++ in a single day, around the year 2005. The domain was capital markets. The code complied the first time and ran with only a few bugs. The code was spread across several functions, but no classes or other abstractions. Only business logic and I/O operations. Written on vi. Not even vim (no syntax highlighting). On a telnet session to a server about a 100 meters away. There were no meetings that day. Never been able to replicate this feat since.

by yashap 3y ago

lovich 3y ago

That was a reference per project, how many engineers have only a single project they maintain? I’ve had between 5-160(way too many to realistically maintain) at every point in my career but it never got to 1. I think the lowest was 3 for a month period inbetween sunsetting one project as the contract had ended and then getting assigned a new project because I had the spare capacity

viraptor 3y ago

There's a level of mature projects where you don't really do new features anymore. There's polish and some changes and focusing on more reliability instead. And in those cases, you need lots more testing and validation and not much stupid code. I had one leg in development and one in operations and had weeks where I merged 10 lines of change - and they were properly tested and important 10 lines and that was how long they needed take. LOC is a silly metric - don't let it become your dick measuring contest or expect it to correlate with level and you'll learn to appreciate the small, difficult changes too. (the lower my LOC got, the longer my documentation, diagrams and project proposals got)

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.

kqr 3y ago

Author here. This is a topic that fascinates me to no end, and I have a million questions for you that are off-topic here. Do you mind sending me an email to a@xkqr.org so I can reply with the things I'm curious about? (Anyone who wants to discuss it can send me an email and I'll try to hook everyone up to the same email thread.)

yashap 3y ago
Will do!

rconti 3y ago

To be clear, I'm not a programmer, but... Wouldn't you expect LOC shipped to go down as level of impact (eg, size of customer base) goes up? 100 lines on GMail has a lot more impact than 100 lines on a homegrown accounts receivable engine for a small business. Feels like it should be (LOC * weekly_executions) at least. And that's before we get into the efficiency of the code.

yayitswei 3y ago

What language are you using?

cdchn 3y ago

Code is a liability. More code != moar better.

vidarh 3y ago

It's easy to spew out 1K LOC/week of low effort code for simple projects. It takes far more skill to produce 125 lines of high-quality code in a complex one. My most productive recent change had a negative LOC count, and will have a big impact. It's entirely impossible to make an assessment of whether or not 125 lines is good or bad in this instance without knowing more about the type of project etc., but that it is a mature project is already a strong indicator the number quite possibly should be fairly low.

postexitus 3y ago

So, assuming that's a growing startup, if all engineers keep committing 0.5/1k LOC/w with number of engineers doubling every year, what will your codebase grow to in 5 years' time? Let's say you have 20 engineers now (low for 8 year old startup). That's 1M LOC/annum. Next year you add another 2M. Where does this go?

kaba0 3y ago

Writing the same CRUD component for the n+1th page, that is not at all fundamentally different than all the rest, is very different than, say, a compiler/render engine, etc. There are days when my only contribution is a single, slightly modified line of code.

baryphonic 3y ago

I had a similar reaction. If I'm healthy, I can routinely ship 1-2k LOC per week. I sort of regret that at times, because I think we could be just as productive (in terms of useful product) with many fewer LOC, but we are stuck with the constraints we live in. OTOH, I've worked (incredibly frustrating) jobs where the infrastructure is dysfunctional such that the write-compile-test cycles are on the order of tens of minutes, and these have made my LOC/week plummet. In those cases, I've recommended to management that we fix the infrastructure to get down to sub-minute cycles (ideally a few seconds), but usually these have been shot down due to their extreme myopia.

gosub100 3y ago

Many mid-large size companies have meetings, code reviews, paperwork, sprint planning that take up most of the workweek. really depends on the domain. If your team is developing a medical device, no way in hell should you push 1k LoC/week. maybe 1k Lo Documentation. My guess is the 125 LoC/week is a maintenance coder role.

hliyan 3y ago

The most I've ever done was nearly 500 lines of C++ in a single day, around the year 2005. The domain was capital markets. The code complied the first time and ran with only a few bugs. The code was spread across several functions, but no classes or other abstractions. Only business logic and I/O operations. Written on vi. Not even vim (no syntax highlighting). On a telnet session to a server about a 100 meters away. There were no meetings that day. Never been able to replicate this feat since.