Ask HN: What's your LOC-to-Developer Ratio?
1 comments
For some napkin math, that's about 100kloc per year per dev, or 50 lines per hour.
Few thoughts off the top of my head:
- How many projects is this code spread over?
- What about refactoring?
- How much time are the developers spending on bugfixing/maintenance compared to building new features?
- Does it make sense to include a half million lines of config?
- Does every developer understand every part of the system, or would you lose "600kloc of knowledge" if a developer left?
Few thoughts off the top of my head:
- How many projects is this code spread over?
- What about refactoring?
- How much time are the developers spending on bugfixing/maintenance compared to building new features?
- Does it make sense to include a half million lines of config?
- Does every developer understand every part of the system, or would you lose "600kloc of knowledge" if a developer left?
- It's all one product, but consists of smaller projects or modules. It's all running a big website and a few sister sites that pull in things from the master site.
- The LOC includes all refactoring. Basically we had a big spike a few years ago as we rearchitectured, and have gone up and down in LOC over the last few years as we refactor away code, simplify, and add new features.
- We're spending more and more of our time on bug fixing and maintenance now. Our systems have gotten more and more complex with business rules and we're now struggling to balance the demand for "new" with keeping things working properly.
- Perhaps including config doesn't make sense if looking at developer ratio. It was easy to get the "all in" number, but easy enough to remove it too for an apples-to-apples comparison.
- No, not every developers knows every part of the system. We will lose 600kloc of knowledge (or more) if someone leaves.
Thanks for your thoughtful questions!
- The LOC includes all refactoring. Basically we had a big spike a few years ago as we rearchitectured, and have gone up and down in LOC over the last few years as we refactor away code, simplify, and add new features.
- We're spending more and more of our time on bug fixing and maintenance now. Our systems have gotten more and more complex with business rules and we're now struggling to balance the demand for "new" with keeping things working properly.
- Perhaps including config doesn't make sense if looking at developer ratio. It was easy to get the "all in" number, but easy enough to remove it too for an apples-to-apples comparison.
- No, not every developers knows every part of the system. We will lose 600kloc of knowledge (or more) if someone leaves.
Thanks for your thoughtful questions!
We're trying to make a case that although we've been able to do a lot that we're well past the sanity point of LOC-to-dev ratio with each developer responsible for maintaining about 600K LOC.
I do realize that it's not a perfect science, but am curious to hear the ratio that you have on YOUR team and what breaking points you've identified in the past or thresholds that you're using to identify when to add people.
I also welcome other suggestions for alternative metrics than LOC that do a better job of showing load-per-developer and any benchmarks for what's reasonable. Thanks!