Guys, can I be honest? I have never actually met anyone who has worked in a LOC-optimized company. This stuff seems like the outrage porn of software engineering.
Agreed. Worse, I have yet to see someone that gave better estimates than someone that could give a rough "good faith" loc estimate.
That is, honestly list out roughly what all code the naive way will touch or generate. Without making assumptions about cheating the metric. If you can bring yourself to that, you can probably give better estimates than you'd expect.
Instead, we seem to constantly look for ways to cheat the metric. With no real reason to do so. Other than push the cheating/gaming into a harder sector?
You misunderstand the intention. You don't optimize LOC but you develop software as best as you can. You measure - among other things - LOC and this gives you at least some hard figures in the fuzzy software engineering universe. See it as the Hubble constant - it gives you answers about the universe provided you know it's value.
Then when it comes to understanding your software costs - it helps you to put some numbers to features. Yes it is dark art but so is all other financial magic. When it comes to maintenance or re-engineering software - LOCs and past numbers can be useful but are not the only determinant of future development costs. There is the agile backlog / planning poker school of thought which is certainly an improvement and valuable running the project but when it comes to large scale software projects it is not an answer I would like to rely on when the project needs a price tag before day one.
It is one metric. If you work in any company purely run on metrics - if you ask me - run once you see a better place. If you work in any company not measuring what it does - run now!
I'm talking about all of these comments on this page with people talking about how LOC/day is not a good metric for productivity. So? No one's tying your wages to LOC/day.
> I have never actually met anyone who has worked in a LOC-optimized company.
Not only that, but the higher-level concept I took away is that, given the size of his features (~6k loc), it takes about 75 days to write a feature. Assuming those are workdays, that's 15 weeks, a little over a quarter. And, indeed, tech companies do seem to measure their process and projections in quarters, and everything tends to slip to the right a bit, on average.
Also, the code coverage numbers line up with other estimates I've seen: life-critical systems should have upwards of 95% code coverage. Standard project: 85-90% coverage.
That is, honestly list out roughly what all code the naive way will touch or generate. Without making assumptions about cheating the metric. If you can bring yourself to that, you can probably give better estimates than you'd expect.
Instead, we seem to constantly look for ways to cheat the metric. With no real reason to do so. Other than push the cheating/gaming into a harder sector?