> Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument.
Maybe because there is none.
One of the main quality of good codebase is simplicity. Which is about how easy for someone else to understand the code. It’s hard to define what simplicity looks like, so the best bet is to avoid the other side, making the code too complex.
And you can make the code complex by shortening variable name, doing code golfing with quicks of the platforms, so smaller LoC. You can also go the other way and increase the LoC by adding unneeded abstractions, repeating slices of code,… There’s a window where the LoC is perfect to attain simplicity, but that amount is an effect of striving for simplicity, not a cause of it. And it’s variable for every problem.
So you got something where the correct value is a different for each case. And trying to manipulate it artificially often results in complex code. And you want to say that is a good metric for productivity?
And in the cases of your projects, there are a lot more info could share that are interesting, like the amount of issues (reported or found by you) that are tied to implementation bugs (coding, libraries API breakage,…) or design issues (requirements conflicts,…), documentation improvement,… Anything that is tied to the actual usefulness of the projects, and not fumbling around with code.
