Slashdot Mirror
American Programmers are Slackers
Amigan sent us a
"Story on the CNN website how that in a world wide
survey of programmers, American programmers are
half as productive - based on Lines of Code generated!"
Allright, I'm lazy, but in Perl thats ok. I find LOC a shoddy
indicator of programmer laziness, but those numbers
seem low- I mean, I probably wrote 15,000 lines of code last year,
ran Slashdot, and was a full time student. I gotta put up
a poll.
There 50 lines of code. I am the king of programmers and will now accept my $300,000 an hour raise.
You know, it's pretty funny. In my CS algorithms class, we just had an assignment which basically involved coming up with a clever optimization for a dynamic programming problem. If you spotted the obvious optimization, you could reduce the problem from O(n^3) to O(n^2). I came up with an even better optimization, reducing the program complexity to O(n).
I wrote my program in Perl. The hardcore coder of the class wrote his program in 'heavily optimized' C++, but didn't spot any of the algorithmic optimizations. My program operated on the sample input in a fraction of a second. His program required two days to process the sample input.
My program was 60 lines long. His program was well over 2000 lines long.
Needless to say, I consider myself a vastly superior programmer, even though his line count is much higher than mine.
All I want to know is, what organizations consider LOC important? I would like to avoid them.
I thought: WOW, I'm going to crush these people. They have no idea. So I got out into the real world and my first job was at Sperry (now Unisys), coding in the OS "kernel" for the series 1100/2200 mainframes -- although it wasn't really a kernel since they had never developed it along the lines of a proper OS.
I quickly learned that "14 lines per day" wasn't because these people were stupid; it was because of all the other crap that had to accompany those lines. In particular, one 500-line modification I added also required 50 pages of (mostly bureaucratic) definition and design documentation and about four months of politics.
Sperry circa 1985 is no longer a good example, but I'm sure that programmer's productivity everywhere is still completely stymied by corporate cultures that require signoffs from 7 different executive vice-presidents just to decide what doughnut selection is available in the breakroom. ("Operations is worried that powdered sugar is getting into the air vents, Personnel is angling for lower fat content to save on insurance premiums, and Steve in marketing wants them all chocolate because HE likes chocolate so therefore the rest of us should too.")
Posted by FascDot Killed My Previous Use:
...but not unproductive.
Laziness is a VIRTUE in a programmer. "Man, I don't want to keep doing this. I'll write a program to take care of it." "It'll take me forever to write that program; there must be a faster way." Etc.
... it's downright deadly. Using LoC as a measure of programming productivity:
- Encourages cut&paste programming ("Look- I just wrote 2000 lines of working code without touching the keyboard!"). The danger of cut&paste programming was ablely demonstrated with the Y2K problem- simply fixing the problem in one place doesn't fix the problem, you have to find all the places that code was copied to and fix it there as well. What should have been a 30-minute fix turned into a multi-year code spelunking expedition.
- discourages black-box reuse- both of older code and of existing libraries.
- discriminates against maintainance programming-
did Linus write 5K lines of code this year? Not much more, in either case. Is he lazy? Of course not.
- discriminates against testing and debugging. I'm a middlin-decent typist (for a programmer), and I can type in one to two thousand lines of code in a single day. Testing and debugging said code can take days or even weeks- during which my code output is exceeding low to non-existant. Last year there was an entire month of busting my butt where my sum total code output was 2 lines (finding the two lines of code in the device driver to fix was a bitch).
- Discriminates against time spent on design. Especially design which increases code reuse, and decreases code complexity and size.
- Discriminates against writting documentation (that's not code).
In fact, LoC Discrimates against all parts of programming _except_ the typing parts.
Programming is not an assembly line production, no matter how much some managers wish it were. There are no easy measurements of programmer productivity. And I do not beleive the American programmer is "lazy".
How many lines is that?
7? (total lines in program including blank lines)
6? (ignoring blank lines)
4? (is '{' and '}' really a 'line of code'?)
3? (#include is not really code)
hundreds? (stdio.h is huge and includes many other header files)
At my prior job, an Indian company was outsourced to re-write the company software for a migration off a Wang system onto an AS/400 with client/server support for PC systems. I had a few problems trying to make revisions to the code that definitely lowered my productivity:
I suspect another issue is that American companies in general have been computerized longer than companies in other countries. This would imply that more work in the USA would be done on maintenance than on developing new code. Maintenance work tends to produce fewer lines of code due to the time spent analyzing the program before changes can be written and applied.
Actually, I'm incredibly lazy. Or to put it more succinctly, I am an incredible slacker (all hail Bob!).
And my lazyness is one of the reasons I'm a great programmer, both in implementation, and in GUI design. I hate (absolutely abhor) to do anything twice. Three times is my max. When I have done something, codewise, 3 times (with small variations), I immediately yank it out and make a new method or class or (C++ Template).
"Europeans tend to have a more disciplined, engineered approach to software development. I think we can carry some of that philosophy over to the U.S. without making people feel like they're being boxed-in"
Software "Engineering" is still something of a misnomer. Software in many respects is still a craft, and discipline is efficiency of design before it is efficiency of effort. If your mind is disciplined, you analyze the problem completely before you code, and your code will be more efficient because of the design (in theory).
"lean more on using packaged software than we do in the U.S...."
I take it this means that they count code generated by code-generators in common GUI building IDE's as "developed code"? Also a major falicy as we all know.
Proud to be a slacker...
"You lack slack, Jack!"
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
I figure the full text, commented out at the end will add to my productivity immensely! But seriously, haven't we gotten out of the "more lines of code are better" mentality back in olden days? From what I can tell, American programmers aren't better or worse than other programmers all over the world, so why do we need this ridiculous metric to tell us what to do?
Ita erat quando hic adveni.
I don't really know why it would be American versus the rest of the world or whatever, but I have always considered laziness as a virtue. Generally it motivates people to produce time/energy savers such as cars, compilers (I know, some of us just love to handcode stuff in whatever our favorite executible format is, but personally I dig how much C and perl accomplish...) and toilets.
I cannot even vote for how many lines of code I have written. Probably 100 different projects between 10 and 1000 lines of code, but most of them really involve cutting and pasting. Hell, if I wasn't so lazy I would probably be using more modular code than I already do and thus write even FEWER lines of code.
I expect on the otherhand that they didn't actually ask any of the Microsoft OS developers. From what I understand they write kajillions of lines of code, as they have to rewrite the OS over again everytime they make a revision.
Wheras with Linux generally you take someone elses code and rewrite the important differences.
So is OpenSource's real value the way it supports laziness? I mean there are all sorts of projects I have done where I have looked for appropriate open sourced code before hand coding. Is this wrong? I would say that a real measurement of productivity would be how much a single programer could accomplish with the fewest number of lines but since the majority of the lines of code written by US programmers are actual productivity wasters like games it is somewhat ironic...
Productivity is measured by how much work an individual can accomplish in a consistent amount of time. The notion that writing more lines of code as getting MORE done in less time is far fetched.
Lazy=good or we would still be hunter gatherers.
DLG
Accurate answers:
Sex: As often as possible. Once a year. Both true.
LOC: 1000. Also true.
Oh, wait. I guess that first question didn't actually say "...with someone else?" If we count Unitarian worship, 500 to 1000 per year.
Pretty pathetic, huh?
Despite all prior comments, I KNOW you're all laughing at my smaller LOC.
Bastards.
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
Didn't we just go through this kind of idiotic misreporting and skewing of data with the NT/Linux benchmarks?
As some of the above posters have mentioned, number of LOC is an extremely foolish way to track programmer productivity. The fewer lines of code used to preform a task the better the end product will preform (generally). I mean if they really wanted just mass LOC why not have everyone slapping programs together with Delphi and we'll all have 6MB executables for our terminal emulators.
Besides, if you go to a descent school for CompSci, you should have the idea of less is more drilled into your skull. I dunno it just irrtates me that someone who manages 3-4 Access DB's (little one's with maybe 3 users and a couple thousand pieces of data) gets paid $60K-$120K a year while I'm building a PHP/MySQL backend for 20-30 different DB's in my spare time between trouble shooting the main IS dept's networking f*ckups AND dealing with all the user issues, for a whopping $25K per year. It's this same unbalanced kind of crap that can cause sloppy coders (who generate more LOC) to be promoted/given raises over the more effiecient ones. Heck that's one of the reasons that we're losing the only good people in our main IS dept. The MIS higher ups are making idiotic Dilbert-esque demands on the IS folks and the talented ones are getting so frustrated that they're leaving. Which means that the IS dept is gutted and people such as myself (in another dept.'s IS) wind up having to pickup the slack and double/triple our workload. Meanwhile management hires consultants at $130-$300/hour to do crap like setup new PC's. And the crowning jewel? The consultants screwup constantly and I wind up having to drop everything and go do it right.
*rant* *rant*
Once more unto the breach dear friends...
Speaking as a member of my friendly neighborhood metrics team, LOC can be as good as any other measure. It depends how you use it, of course.
I agree completely that evaluating someone based on how many lines of code they have typed is really stupid. But I have trouble believing that many functioning companies use LOC in this manner. The correct use of metrics, such as size (indicated by lines of code or function points or whatever), is in generating estimates and tracking actual progress to those estimates, so that the project manager can tell if the project is on schedule. In this sort of application, LOC are generally counted based on the code affected by changes - that could include new code, modified code, or even deleted code. This number is then cross-referenced to historical data / estimated data (depending on use) to allow analysis.
using lines of code, or any other metric, to evaluate an individual is strictly forbidden by my organization, and hopefully most others. Once you start evaluating individuals based on metrics you can throw out all hope of gathering useful information, because everyone will be covering their asses.
Those 8,000 lines were almost all Perl. How many lines of C to do the same thing?
Feel free to multiply by 5
It seems stupid to base productivity on the number of lines you code. Just look at almost any M$FT product, they have an incredible line count but not many of them are very productive. If line count was a measure of how good a program is then all bloated M$FT programs would perform really well. When I was in high school our programming teacher told us to try and find an algorithm that was the best solution with the least amount of code. So if coding fewer lines make me a lazy american programmer then so be it.