3 ms·

Why is it outlandish? You're confusing the reliability of using source lines of code as a metric for measuring the productivity of developers with measuring the

Why is it outlandish? You're confusing the reliability of using source lines of code as a metric for measuring the productivity of developers with measuring the complexity of a system. It's a bad metric for measuring productivity but a good metric for measuring complexity. The problem with using lines of code as a metric for developer productivity is precisely that it leads to developers introducing unnecessary complexity into the system since they try to add as many lines of code as possible for implementing any feature. There is no drawback in keeping the source lines of code to the minimum amount necessary to get the job done.

tromp 5y ago
It may be outlandish because minimizing the number of bits, when taken to the extreme as in Algorithmic Information Theory, leads to very obfuscated code [1]. [1] https://www.ioccc.org/2012/tromp/hint.html https://www.ioccc.org/2012/tromp/hint.html
cryptica 5y ago
I find this to be true even in cases when you have large projects. Sometimes the scale of the project will necessitate adding 'extra complexity' to a specific set of core modules but this is only in order to reduce the complexity of other peripheral modules. IMO, you should never add extra lines of code to a module beyond what is immediately necessary unless it allows you to reduce even more lines of code in other parts of the code.
okl 5y ago
I've never proposed using LOC as a measure of productivity. I won't entertain your dishonesty any further.
- cryptica 5y ago
  Well in that case I really don't understand your reasoning. I can't think of any other reason why you cannot see that lines of code is the closest and most measurable representation of the information content of the system's logic. Information content/entropy is the most rigorous way to measure complexity. IMO, lines of code is even better at measuring complexity than compiled bytecode because it accounts for complexity from the developer's point of view (which is what the question is asking). While some lines of code require more effort from a typical developer to understand than other lines, it doesn't matter so much once they're averaged out over thousands of lines and thousands of different developers (each with their own slightly different perception of complexity). It's reasonable to factor out individual perception of complexity.

tromp 5y ago

It may be outlandish because minimizing the number of bits, when taken to the extreme as in Algorithmic Information Theory, leads to very obfuscated code [1]. [1] https://www.ioccc.org/2012/tromp/hint.html https://www.ioccc.org/2012/tromp/hint.html

cryptica 5y ago

I find this to be true even in cases when you have large projects. Sometimes the scale of the project will necessitate adding 'extra complexity' to a specific set of core modules but this is only in order to reduce the complexity of other peripheral modules. IMO, you should never add extra lines of code to a module beyond what is immediately necessary unless it allows you to reduce even more lines of code in other parts of the code.

okl 5y ago

I've never proposed using LOC as a measure of productivity. I won't entertain your dishonesty any further.

cryptica 5y ago
Well in that case I really don't understand your reasoning. I can't think of any other reason why you cannot see that lines of code is the closest and most measurable representation of the information content of the system's logic. Information content/entropy is the most rigorous way to measure complexity. IMO, lines of code is even better at measuring complexity than compiled bytecode because it accounts for complexity from the developer's point of view (which is what the question is asking). While some lines of code require more effort from a typical developer to understand than other lines, it doesn't matter so much once they're averaged out over thousands of lines and thousands of different developers (each with their own slightly different perception of complexity). It's reasonable to factor out individual perception of complexity.