Actually, source lines of code is a very common metric, certainly for larger projects. I skimmed this Wikipedia article and it covers the basics:
en.wikipedia.org
People may be shocked at two values:
Total Lines of Code for Any Modern Operating System
Take the time to look at the Wikipedia article. Scroll down to see lines of code estimates for old versions of Windows and Linux.
->
It says that Debian 7 (2012) had 419 million lines of code. It is a staggering number to me and that was over 10 years ago.
Estimated Debugged Lines of Code Per Developer Per Day
Project leaders use "debugged lines of code per developer per day" values as one aspect of project planning. One of my favorite books on this subject is "The Mythical Man Month" by Fred Brooks, published in 1975. It is a seminal work in the field; a post-mortem of the lessons learned from managing IBM's System 360 project.
->
In that early book, the author tells us to estimate 10 "SLOC" (source lines of code) per developer per day.
(I never saw anyone use boosted lines per day values (e.g., 20 or above) and get away with it. I view it as an "anti-pattern" - a behavior which will lead to failure. From my experience, sellers promote products that claim to yield huge increases in developer productivity. Management "drinks the koolaid" and takes the product or service hype as the basis for unrealistic estimates of cost and schedule for the future project. Sometimes it is a deliberate trick to win a contract or executive approval, with the expectation that overruns will be covered in other ways - change orders, too late to cancel, etc. Sorry to be so brutally honest about it.)
Related, and equally shocking to average people:
Bugs per 1000 Lines of Code
Look up typical numbers for "bugs per 1000 lines of code". Those are the bugs that still remain in your products. They shipped the product to you anyway, knowing that it had bugs. (Imagine that!) A few of the bugs are known, most are not, and most will never be triggered, ever. Values range a lot and need context. Do a quick search for "bugs per 1000 lines of code."
VERY IMPORTANT:
Many bugs may never be encountered in real life, which may be why they were not caught. Individual developers vary wildly in their production levels. The most productive developers may also be the ones who generate the fewest bugs.
Without context, understanding, and proper interpretation, you can easily jump to unwarranted conclusions.
Do not ascribe too much value or utility to this post. It is as more about sharing those unexpected numbers for your amusement than it is about providing you with useful information that you can apply to your Linux systems. You won't win bar bets with it.
Ignore:
(One developer who worked for me could easily generate hundreds of lines of code a day. Okay, some days, but she was very productive. She was beloved by all for her ability to create proof-of-concept but fully functional demonstrations very quickly. Customers were "wowed." The problem was that nobody could read, understand, review, modify, or maintain any of her code. Putting her in a production environment would have been two tragedies - to the team and her.)