I like to use LOCs to see at a glance the size of a project. A more complex business logic usually takes more LOCs to write it down. And I bet there is a strong correlation between LOCs and hours worked on a project which would make LOCs a good approximation of work done. Actually I should research it. Should be not too hard to find all the tickets for projects and compare the time logged to LOCs.
1) There is no fixed correlation between LOCs and business logic complexity.
2) there is actually an inverse correlation between LOCs and amount of work done. When I'm most productive I actually decrease the LOCs.
1) You tell me that if you take some fixed business logic and add some exceptions to it (make it more complex) you wont need more LOC's to address this added complexity? I don't believe you.
2) You can't be productive having 0 LOCs. So 0 LOCs = 0 productivity. n>0 LOCs = (presumable) some productivity. I would say we have a trend.
1) I said that there is no fixed correlation.
2) I'm most productive when my LOCs are negative, deleting duplicate code or finding a better approach for a problem.
1) so you say there is a (positive) correlation, but it is not "fixed". Sorry, I don't understand what this means.
2) I know what you mean. I do it often myself and I know it improves code quality. It's not my intention to measure "work done" in LOCs, which, as you say, could be contradictory. I propose to measure the size of a project in LOCs. Suppose, you have two projects. And you have all the time you want to reduce their LOCs (to improve code). After you are done, both projects will still have some LOCs. My point is that the project, which has more LOCs, after you had your fun with it, is the "bigger"/more complicated project.
1) Imagine some project written using CTRL+C, CTRL+V everywhere, another much bigger project written with some good architecture and using always the DRY principle, another one still bigger is written in a much more compact language like F# or Haskell. The first project following your criteria is the bigger and most complex, but in reality it is just a bloated mess.
2) It never works like that in reality. No one is paid to spend time only to improve the code, we are paid to provide value to the users. The project with the good architecture is easier to work with and it will be easier to add features and continue to improve the code. The bloated mess will be much more difficult to work with and you won't have the time to improve it apart from getting the low hanging fruits.
I think LOC probably works OK as a very crude metric until you start to measure it. Once you start to measure it all hell breaks loose. If you measure me on lines of code, well I can get you lots of lines to code. No problem at all...
I seem to recall a quote from some computer scientist, possibly Knuth but I'm not sure, that went something like 'You optimize what you measure.' So if you measures LOC, you get LOC... and far more of them than is by any reason 'necessary.' Really a horrendous metric.
