| No, we don't misunderstand it. 10 lines per day is just rubbish. Here's an example: https://github.com/sumatrapdfreader/sumatrapdf is code written by 2 people (me and another guy). It's written, documented, tested and bug fixed. It's 110k lines of code. And it's tight. Good luck removing 10k lines of code and not loosing any functionality. Assuming 10 lines per day and round-the-clock 365 days of working, that's 30 man-years of work. 15 years for 2 people. I didn't spend 15 years writing it. It's a part-time effort over 10 years. The 10 lines per day is off by at least an order of magnitued. And I don't claim to be spectacularly productive. Jonathan Blow wrote 90k lines of code for Braid in 1 or 2 years. |
You can't rewrite much without the risk of breaking things, so you need a lot more testing. There's a lot of value in the code, so there's more to leverage to add functionality, but the other side is there's more to learn and analyze to efficiently leverage. And when there's lots more teams working on the code, there's more of it and it changes faster than you can expect to fully comprehend; you're continually analyzing and learning.
When I'm off on my own, spiking a new service or library, I can churn out 10k to 20k lines a month; it's very easy when it's greenfield, when there's no team coordination overhead, when you don't need to refactor other people's stuff when you redesign, you don't need to go through full code review cycle, the whole thing fits inside your skull etc. But that doesn't last forever, and it's not business as usual for feature development.
Fixing a gnarly bug might take several days of investigation and end up with a 1 line fix; and delivering that fix might make the difference in avoiding 6 or 7 figures worth of revenue churn. Does that mean it's 10000x less productive?