|
120,325,116 lines of code....no less, no more. duh. easy question, next?! 
|
|
|
|
|
I'm finding that as the years go by, I'm writing less and less new code. That is to say, I encounter fewer situations that I haven't already dealt with. Being lazy, this leads to either copy/pasta and probably some customization, or better the creation of a reusable utility function.
Also, the IDEs, particularly intellisense are so much better these days than when I started...this code was generated by a tool. 
That said, a rough estimate would be around 1.8M in 20 years, around 90K/year average, but as stated, the majority would have been written in the first half of that time frame.
"Go forth into the source" - Neal Morse
|
|
|
|
|
When the VAX supermini was every programmer's dream, DEC published statistics showing that the average production volume for those developers writing the microcode for the 780 (the firs one in the VAX series) was 250 (micro)instructions a year.
Everybody knows that you do not leave microcode writing to the novices - those programmers were among the very best that DEC had. Yet it took them, on the average, a full day's work to figure out a single instruction.
Since the 780 was the first crop, I guess lots of the effort went into competence building, learning the tools etc. Maybe it even included some tool development. I don't know how DEC did the counting, only that the total number of microcode instructions produced divided by the number of microcode programmers returned about 250 instructions/year per programmer.
|
|
|
|
|
Approximately 1,243,867, but only 12 without bugs.
Technician
1. A person that fixes stuff you can't.
2. One who does precision guesswork based on unreliable data provided by those of questionable knowledge.
JaxCoder.com
|
|
|
|
|
"Lines of code" is a rather meaningless metric, since you can rewrite a line many, many times. And what constitutes a "rewrite of a line" anyway, if a single line then gets broken down into multiple lines (or vice-versa) after some refactoring?
|
|
|
|
|
Wouldn't it be more interesting how many keystrokes you typed?
if (i==1)
vs
var result = MyWonderfullData.Where(x => x.FullNameWithoutSpaces).Select().OrderBy().Etc().Etc()
makes quite a difference 
|
|
|
|
|
My whole career was spent programming. My first full-time job after university was in 1972, aged 21. I retired in 2017, aged 66. So I worked for around 45 years. I used to count lines of code at various points and my estimate was that I created around 30,000 lines of debugged production code per year. In the early days it was assembly code. Later it was Pascal, C, C++, Java, VB, C#, Objective C, etc. I think the line count remained the same. I was just more productive in the more recent technologies. So whereas my 30000 lines of assembler code for a PDP11 might have occupied 64KB and was the only code running in the machine (no operating system), my final applications occupied tens or hundreds of megabytes, especially with all of the libraries they brought in.
So if I did 30,000 LOC per year for 45 years I must have produced well over one million LOC in my career.
And thinking back on the last 2 decades I would say that at least 300,000 of those lines are still in production: 1 desktop app, several Android apps, 1 IOS app and a good proportion of a SAAS webserver-based app.
I do not think I ever wrote 10000 lines in a day, even on my most productive day. I guess I often did 1000 or more, especially when it involves a lot of copy/paste/edit. But that was balanced by other days where the emphasis was on meetings, planning, testing, debugging etc. I find it hard to believe that anyone personally (i.e without machine aid) created 10 million or more LOC in a career. E.g. 45 years of 40 hour weeks and ignoring holidays is only 336 million seconds so 10 million LOC would mean creating one line every 33.6 seconds.
modified 26-Jul-19 6:07am.
|
|
|
|
|
All of these different methods are simply a volume metric and are roughly correlated. But, consider that for a blank link you have to hit the enter key. For a comment, you actually have to type it. For code you also have to type it. For both code and comments you have to think about it and since the comments are about the code, that is relevant. Documentation outside of code also counts in the same way, but probably stripping off the formatting is reasonable. So, simply take the size in bytes of all of the source files. Perhaps it would be worth while to compress each one and then total the size. That would tend to reduce the effect of spaces / tabs and repeated variable names and the length of variable names. Compressing everything together would result in too much reduction in size due to similarities across programs that don't really reflect much.
I have found that, in practice, a simple volume metric is a very good predictor of performance and and time required to complete a project.
|
|
|
|
|
A parallel: Technical writers produce 1 page per working day.
At least when I was working with documentation, that was commonly accepted, both by writers themselves and management. It matched our writing department quite well.
30+ years ago, documentation was 98% text, produced with rather primitive tools. Later, modern tools made it much easier to add graphics and other illustraion, typographical effetcts etc. which made the documentation look more "professional" quality. But in spite of more automated and fancy tools, production as measured in pages per day didn't increase: Making a figure to illustrate a point takes as much time as describing it in text.
I haven't been in documentation for years, and nowadays, I guess most software documentation is written by the programmers themselves (so it makes no sense to the users...), and counting number of pages for online documentation is not as easy.
I guess that you will see much of the same as programming languages evolve: The line count produced by an assembly programmer, a K&R C programmer, a Cobol programmer, or a C# programmer would be roughly the same, even though the functionality provided by those "x" code lines vary greatly. There are some obvious exceptions, such as microcoding or APL, but for the algorithmic class of languages, it seems like the variation in line count is not that great.
|
|
|
|
|
To paraphrase Bob Dylan:
"How many lines must a programmer lay down,
Before his lifetime is done?
The answer my friend is blowing in the wind...."
|
|
|
|
|
I'd like to add the most wonderful blues for developers, from Simon and Garfunkel:
Hello Source code, my old friend...
I've come to talk to you again...
Because a vision softly creeping
Left its seeds while I was sleeping
And the vision that was planted in my brain
Still remains
Within the code... on servers...
|
|
|
|
|
I saw Paul Simon on his farewell tour and he's terrific!
A little John Kay and Steppenwolf back at you
"Code me baby, code me baby All Lifelong"
|
|
|
|
|
I'm writing poor code, nobody loves me
"HE'S WRITING POOR CODE FOR A POOR LIBRARY SPARE HIM HIS FAILS AND HIS DEPENDENCY!"
|
|
|
|
|
You Win! that is the best!
"Scaramouche! Scaramouche! can you code a little better?
Spare him his life from this framework that you see!"
I played R&R R&B for 30+ years. Got tired of the drama and gave up.
|
|
|
|
|
How about "code life years"?
The average app's life is 5 years; if yours go "legacy", is there a bonus?
How about a death march that gets canned? A wash? Or do you go negative?
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
I agree! Young programmers today have it REALLY EASY... when I was in my 20's, it was the late 80's and everything you wrote was original. There was no internet, no github, no codebase we were taught and got in the habbit of writing reusable functions so you could use them in other programs. When you bought the Microsoft C compiler, it came with a library of manuals. We used to hire engineers based on how many they memorized, because the more they had memorized, the less time they would spend function searching.
Today, all the reusable functions are online, the manuals are online, programmers today just patch together the methods we wrote in my generation, put together a UI, debug and they have a program. The only "real" programming comes in those rare cases where the code is not available online.
The outcome, more programs are published...but are they comprised of lines of code written? I would estimate the real number is less than 10% for most applications!
|
|
|
|
|
Top will keep the wearer entertained ? (10)
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
I see what you did there!
But I'll let the others have it - I did yesterdays.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Fascinator (a highly expensive, ineffective head covering worn by posh women at racecourses and weddings).
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
you are up tomorrow
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
|
the goat in your machine wrote: must watch - YouTube
Nope. I don't have to and I won't. I'm guessing Rickrolling ... or worse, a Justin Bieber track. 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'm not THAT evil, (just baaaaad)
|
|
|
|
|
That is exactly what an evil person would say ... 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
