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 certainly is an order of magnitude difference between the productivity of good and bad coders. A company that could reliably hire only the good ones could afford to pay them $200k per year and still make a killing.
However, you can't really measure productivity in lines of code. At the beginning of a new project, everyone writes tons of code. Once a project is fairly mature, maintenance involves more reading and less writing. I wrote about 14000 lines of code for my fun project last year, and only about 7000 lines of code at work, even though I spent much more time on the work code. Most of that, again, was on a couple of new projects. Less productive at work than at home? Nope, just spending a lot more of my time reading and debugging and testing and making one-line fixes.
If we write half the amount LOC they do, that means we're twice as efficient! (Well more so, since the files will be smaller, faster, etc...)
Well, I Learned COBOL and RPG (yes, I'm laughing, too) in skool, but now I use C PERL and Shells.
nme
... or the exact same code with less debug code in it (traces, exceptions, asserts, etc. all the things that make working with other programmers bearable.)
I'm involved in a large E-commerce package and wrote a simple parser in JAVA to handle "enhanced" HTML pages. This includes code to access live data from a proprietary BBX accounting package and a SQL interpreter. There's also some PERL and JavaScript code involved.
So, approx.
Java - 5K LOC
PERL - 2K LOC
HTML/SQL - 5K LOC
JS - 100 LOC
Sam (Yep, still too lazy to create an account)
Or even LaTeX?
100K each in '96 and '97
STUPID engineers produce 10 lines of code a day.
Brilliant ones can do orders of magnitude more
No, STUPID engineers produce 10 lines of code a day.
BRILLIANT ones produce 5 lines of code a day, because they now how to things right and efficient without bloat.
I agree. As most of us who have done any coding realize, the elegant, simple 20 line function is always preferred to the clunky, hard to maintain 100 line function. The first programming lesson you learn is how to print "Hello World" on the screen five times. The second lesson you learn is how to use a loop to do it in a three lines of code. LOC == laziness? Methinks not.
Does a line of assembler count as more than a LOC becuase it takes longer, or less because it does less?
Person 1, because most of the extra 10K is likely to consist of comments.
Wasn't this sort of thing supposed to go out with procedural languages? IMHO, I would guess that many other countries use more procedural (read:older) languages than in the U.S. Probably a good chunk of the first world is looking more to OO tech (US, Canada, most of Northern Europe, Japan, etc), but how much OO development do you think is going on in Chin, Russia, Malysia, etc?
Less code per year makes sense in environments where OO technology is being implemented: There is more planning, MANY more work products, and code reuse seems to be preached more often. Call OO environments more design and analysis intense, less code intense. Less KLOC's sounds good to me.
If you keep preaching KLOC's, eventually your code will look like crap. (remember when Pointy Haired Boss was going to pay by the bug fix, so Wally was going to "code himself a mini-van this afternoon?"
Peace
I prefer the latter. You waste a whole line
the other way. I find it nice to see as much
code as possible on one page.
--ac
will I believe that C is not _the_ primary language of choice. C has achieved that mystical balance between being low and a high level language while being itself a small language. Nothing else has yet matched this. Everything else is either too bloated, an ugly add-on kluge to C, a scripting language that is too limiting for many necessary uses, etc.
C is still king.
And `South American'.
No kidding! Ever do much GUI work with the visual editor in VAJava? WOW, talk about extra lines of code!
At home: C, UNIX scripting, SQL, APL & just starting to play with Perl.
Pat
4th sem NAIT CST
Question:
Does the LOC count include comments?
I'm glad that so many of you love to program. That means that I never have to. =)
Sure, I can modify a couple lines of code if I need to to make something work. But generally, programming makes me nauseous.
And yes, you can get many many benefits of Linux without having to know any programming. If that weren't the case, then why are we trying to push Linux as an alternative to Windoze? How many Windoze users know how to program?
Aen
http://toolshed.down.net/
And I remeber a `star programmer' was supposed
to do 10 times more. I could not believe when
my calculator showed 160 a day (but then, it was
not _fully_ debugged, but almost).
6x12 hours on average, also
-- `The 100K guy'
I code in Visual MFC wizard (read Visual C++).
insert rant about how Microsoft managed to turn C++ into little more than a scripting language for their misguided class hierarchy here
As an American programmer who often works on projects outsourced to India I know I write half as much as these coders. However, my stuff works right the first time, is efficient, and doesn't have to be sent back for bug fixes. Of course these guys write twice as much code as me since they have to do everything over and over again!
So you write a few lines of code. You friend writes pages of them. The question is... who's program is more efficient? More useful? Writing long pages of code for a worthless program is pretty dumb when you can write the same program in just a few lines of code. And speaking of lines of code, how would you treat a comment? /* is this a line of code? */ #is this?
Actually, I'd be surprised if very many companies with Y2K COBOL problems actually still had the source code and compiler still lying about. Fixing Y2K bugs in binaries, ugh, now that'd probably be more realistic, less fun, not worth the extra pay, and maybe just impossible altogether.
The reason the LOC counts are so low for american's (at least this american) is that we have to spend all our time cleaning up the sh*t that these "highly productive" people have produced.
I have work with several companies who had both foriegn consultants and off-shore programmers. In either case, the work sucked.
The Indian programmers that I currently have to work with produce code via cut-n-paste. Imagine what your productivity would be if you un-rolled all of your loops and in-lined all your subroutines. This is the code they produce and the reason why my productivity numbers are so low. Hell, my LOC is probably negative from all the code that I have had to swack.
Did we forget Objective C?
I know no COBOL, but I'm fast. I've actual experience in about a dozen languages from different paradigms.
For that kind of money, and a short term, I can break my promise to stay a COBOL virgin.
Smalltalk!! Still my favorite and the most productive for large scale things. Sucks for low-level stuff though...
And Java and some C (if I have to).
Use whatever works to get the job done.
Macro writers, those who proficiently write stuff for languages with eval string type statements, etc etc etc..
Besides, when I write code, I try to minimize the typing I have to do, unless I am trying to make the code more efficient or something.
Boy we are a touchie bunch!
Not necessarily, as there is a point of diminishing returns. I have worked with programmers who took immense pleasure is writing code in the fewest lines, to the point where it became the ugliest, hardest-to-debug-later code in the project. Not to mention the fact that it took them much longer to write "pretty" code than to just get it done. Most of the time, their code ended up looking like the C code from the Obfuscated C Contest. What a nightmare!
Hey, are you the
;-)
"Will write code that writes code that writes code for food" guy?
Lisp. We write as much as you, but it does 10 times more, we are happy, and we still have hair.
100K of C++. It's bad enough I had to use that.
I'm definitely not writing any script crap.
Yeah tons of silly Motif code generated by RapidApp that could be replaced by an Xmt
line and a resource file.
`Visual' programming sucks. Declarative is the way to go.
If you write a program that performs a desired function in 10 lines vs. another programmers implementation in 100 lines...who's the better programmer? :)
I crank out over 20K lines per month. Usually of tight clean C++ code. The NT service I started writing two weeks ago alone is 3K lines of C++.
Mind you 3 lines of perl can do strong encryption, so perl can't be measured by LOC. Maybe by file size in K?
If I had used Lisp I would have still had 100K lines, but it would have done 10 times more
(indeed, the program could only be started to be considered `functional enough' at 1M lines of C++).
Where did I read this? I don't remember. But here goes...
Micros~1 and IBM were collaborating on the OS/2 system, and a MS programmer looked at some IBM-generated code. About, what, 15000 lines? He folded it into a couple of hundred lines. Good stuff, no?
Well, the IBM managers now tried to bill MS for the code revisions? They were mad because that programmer set the project back considerably. It seems one of the metrics was LOC, and you always get what you aim for.
FWIW, I believe Yourdon mentions this in "Decline of American Programmer", where a Russian factory producing camping cookware was measured by steel consumed. What did they produce? Overweight pots and pans, of course!
I want to say, this article is full of sh!t. The idea of american programmers being 'complacent' and 'fat and lazy' is a total crock. The only other field of labor that pulls as many hours as a web, data entry, or sysop coding are certain medical professionals that work emergency wards, and possibly some journalists.
I find it interesting that business managers critique programmers, when studies show that managerial positions that don't directly handle programming work the fewest billable hours in any IT field. Just because they wear ties they are closer to the money.
Of course programmers are overpaid. They work hideous hours on deadlines in a market that there isn't enough labor to support the demand, and in a job very few people, frankly, have the intellectualy capacity to handle.
LOC measurements are inherintly flawed. That's like rating an author based on the number of pages their book is. Just because someone writes more lines, doesn't mean they are better programmers. (Actually, if someone has to write more code to do the same thing, it proves something about their talents, and lack thereof). If you want to rate programmers on anything, rate them for 'billable hours', 'training', and 'experience', with such easily flawed LOC measurements a distant secondary concern.
#include int main(int argc, char **argv) {printf("Hello World\n");return0;}
..
At work, I have to use COBOL/SQL stuff. At home, I'll use/experiement with damn near anything.
One can see many instances where European software is better than American products. Unfortunately, a lot more is developed in the US, and stupid people at the EU and such will mandate on the use of crap as Word.
There surely are untalented programmers around, but I suspect there're HUGE masses of bad hackers in the US. I don't know where the proportions are bigger.
Where do you get your `non-natives' from? Or maybe the good ones grew up and were smart enough to give up on money for a being able to _live_?
Yeah, the Progress WebSpeed code I wrote last year would fit on one floppy (with tons of space left), but it creates over 10k LOC (HTML) a DAY!
TK
I couldn't agree more. Also, how many of us are also system admins and help desk gurus. How many of ushave to do things five times because "Systems Analysts" can't get their shit together. Do other countries even have stupid ass Systems Analysts?
I remember my first programming class and a 20 line program to add two numbers together. (And only 2 numbers, change the numbers meant changing and recompiling code.) Now I can do that with about 3 short little lines. ( more or less) does this mean I'm less productive? Nope, it means that while some dumb cluck is still trying to write war and peace I've got a program up and running so that the rest of the office can be productive. Write once, compile once, run fast. That my friend is productive. I gave an assignment to someone to write a program in c++ two weeks ago. Yesterday one of the junior programmers came in with a 40 line perl script that does the job and quickly. Now who do you think will keep his job at the next review. The c++ guy may be writing more code. But my opinion is that the perl guy is more productive. The jobs done and it runs.
oh and the names Nightwriter, forgot the dang passwd.
Delphi ! (worlds best programming language/dev tool ever made on this planet). PHP3, assembler (make it fast !).
;-)
did learn C++, Cobol, ADA, Smalltalk, VB, prolog, Lisp, etc...
in my opinion C sucks, too many pointers everywhere and too loose syntax which makes a lot of bugs. I remember seing a study saying that Pascal programmers made 20 times less bugs than C programmers (I can hear the flames coming
Gee. I guess I know why this `Lennon' got shot..
I am obviously so much more productive
than all you 6-line losers!
What one person does in 100 LOC and what another person does in 50 LOC has no bearning on the quality of the work, or the productivity.
A Cracked Canuck
I was being s-a-r-c-a-s-t-i-c
Thank you U. Waterloo.
The profs are sitting back having a good laugh right now for making us use that "language".
Yuck.
In the wee hours of the morning I could usually be found using Perl, Java, or C++ doing projects on my own time, or VBA stuff for Access for on the side $$$
Am I the only one who gets them all confused sometimes?
So they go on using LOC to measure productivity --
something I'm not going to attempt to argue here.
Then they give explanations of the measured
productivity that have nothing to do with LOC!!
Dig it at the end of the article, where they talk
about "lack of reliance on 3rd party dev tools"
and "redundant coding efforts that cause multiple
people to be working on the same stuff." Uhh,
these types of development practices generate
lines of code just as fast as anything else.
HEL-lo!
Just one problem among many with the article... I
get the feeling that the people who conducted the
poll are far less competent than they accuse
American programmers of being.
-J.
As many have already stated, LOC is a convoluted, often misleading metric for coding efficiency and effectiveness. For instance, I write scientific applications using a mixture of C/C++/X/OpenGL/Motif. 1K LOC worth of hard core numerical analysis is fairly difficult to write as it must perfectly merge theory with implementation. Usually this requires convoluted indexing and pointer (vector) manipulations. Debugging and testing the numerical accuracy of the code is non-trivial.
OTOH, I'm required to write the graphical interfaces using primarily X & Motif. Well, just putting up "Hello World" constitutes a lot of LOC. Any decent interactive X/Motif program takes up several K LOC! Simba the monkey (suitably trained, of course) can write a Motif interface with several K LOC.
Changes or additions to legacy code is extremely tedious work. Just adding 10 LOC can be a difficult task because you must: 1) find where the changes have to be made, and 2) insure that it does not break anything. Last week someone asked me to do a simple patch to some legacy Fortran program (yikes). This took me hours to do. You try to figure out GOTO(1,2,10,2,20,10),ITYPE
I won't even comment on code reuse.
Because of different designs (and coding style) LOC is worthless. LOC has no relation to the functionality of a program. Little example.. Program A has a small parser that reads a file and does commands based on whats in the file. Program B has everything built-in which adds more to the LOC. Which do you think would be more useful? The one with simple commands you throw in a file, or the one with everything built-in?
Anyone who has ever looked at obfuscated code knows that functionality can come with very few lines of code. Lower LOC count does not mean the code will be confusing (like obfuscated) either.
Different styles add to LOC too:
int main(int argc, char **argv)
{
printf("Hello World!\n");
return 0;
}
LOC: 5 lines
int
main(int argc,
char **argv)
{
printf("Hello World!\n");
return 0;
}
LOC: 8 lines
Same function, different style. Also, what happens if the coder throws in a few #ifdef's or comments? An #ifdef can switch code, totally remove code, or add more code to the binary. How do you count that?
Work (Academic): research in DSP, signal compression and VR: C/C++, easily over 20 KLOC trying out different algorithms.
Home: Audio DSP, Sound Synthesis, the fun stuff: x86 Asm, C/C++, Common Lisp
LOC is a bad measure... elegant design and using reusable components bring LOCS down a lot... LOC does not equal functionality. It is also very language dependend: Generally 1 LOC in Prolog > 10 LOC in C. It all depends on the expressive power of the language.
Using,for example, the COCOMO metric to estimate the amount of work required and then measuring the success with respect to that might be a better approach.
Lazy overpaid US worker, lets bring in lots of hardworking folks who'll work for much less since it's a sh*tload more than they make back home. No time zone problem and we can drive down the market rate for programmers and other high tech types. It'll save the company tons and increase the wealth for the all read way too rich investors. Humm. real easy place to look for "profit" is cutting your labor cost... Hope you all have backup plans when you get over fourty and have priced yourself out of a job.
As some people have hinted at, the programming language being used greatly influences the number of lines of code required to implement the same functionality.
Here is some conjecture of the lines of code required to do accomplish the same thing in various languaes:
COBOL 500 lines
C 150 lines
C++ 100 lines
Java 100 lines
Smalltalk 70 lines
Dylan 50 lines
Cecil 50 lines
Lisp 35 lines
I made these numbers up, but I think they are approximately accurate.
Has anyone ported the DeltaBlue and Richards benchmarks to Python and Perl?
I can't beleive this article. A lot of the other points are valid (more shorter lines vs. less longer more convoluted lines). LOC don't matter at all. KISS is all that maters. Simplicity and clarity.
- The original anonymous coward
PS: I used to work at a bank where my boss had in is office a quote that went something like: "a programmer writes code right the first time, gets a pat on the back. A programmer who writes it right the 20th time gets job security." Fuck that.
Measuring productivity by lines of code is stupid
"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
-- Bill Gates
Hey, the man's not a complete idiot
> And I'm sure some guy out there will just run vi > (or emacs for the sorry vi-challenged people), > type one 'printf("wheee") ', and then yank and > paste 'till the sun comes up, and legitimately > call it his 1000 (or 1000000) line program...
Actually, just p100000p will do the job. He can go get some coffee or a few minutes of sleep or something while it completes.
Dylan
C
C++
I need C and C++ less and less as Dylan implementations get better.
More of us stupid Americans are using object oriented programming languages... damn that code reusability, it makes your KLOC output go right in the toilet!
Do the people who measure programmer productivity in lines of code also measure the desirability of their lovers in pounds?
I find that changing my underwear usually gets rid of that warm, squishy feeling...
A computer program is like a work of art; it is complete not when nothing else can be added to it, but when nothing else can be removed from it, and still have it fulfill it's purpose...
Hardly... wankers, yes, but slackers, no!
But then, I teach a Java class...
I have to admit that non-USA computer scientists
invent nifty things like object oriented programming, the world wide web, algol and LINUX.
But for the most part the USA companies reap the commercial benefits. IBM, MicroSoft, Apple, to name a few. SAP was a [ temporary ] exception.
I wrote a 6,500 LOC program this past December (in C and according to whatever my source metric tool's idea of a "line of code" is) and didn't consider it a particularly big project. If I count the 1000 or so lines that I wrote and then later rewrote, that takes me up to this article's idea of a year's worth of productivity. Does that mean I can kick back until next December?
Granted, LOC is a bogus measurement, but those figures seem awfully low to me. If the Europeans are taking this seriously, maybe I should move to Europe and replace six of their programmers.
Everytime someone attempts to include coding segments in a post, the formatting and things with angle brackets gets mangled. We need a new HTML tag, <CODE> and a corresponding </CODE> to prevent chunks of codes from getting mangled up.
This is a serious question. I do a lot of verilog programming work in my job (mostly rtl), but I am judged not on how many lines of code it takes to write, but does it perform the function specified. I rarely even notice how many lines of code are in a specific file, much less try and figure up how many lines I have coded within a period of time.
I said over 20K, but that doesn't make me proud. Too too much of that was trying to wrap my POSIX/C background around Microsoft's Visual Basic hinderances. Quite literally. A wrapper here, declaring undocumented win32 kernel functions there. Half my time spent on fixing and interpretting VB's API (or lackthereof) instead of building the app. Modularization? Yeah, but no reusability.
[The ability to use VC++ (which really isn't C++, is it?) or ActiveX in VB equates more to money than it does to good programming practices. Give me a mundane but standard C library or a tardy but thorough Java API anyday.]
Now, if VB supported inheritance instead of polymorphism, or if I could just scrap it and code in Java, I'd have been done in a fourth the time with an eighth of the code--not to mention the delight of being proud of my Booch diagrams.
I've heard quotes from Microsoft execs touting their best programmers are able to pound out 2000 lines of code a day. If I kept up that pace, I would never produce anything that worked or was reusable. Hmm, does that ring any bells?
\007
1000 lines of planned code is great for my day--that includes testing, debugging, and poring over thousands of lines of BAD AND USELESS DOCUMENTATION. Some would say I am slow. Others might say I am thorough. I still say that I am using the wrong programming language.
Wonder how many lines of frustrated slashdot commentary programmers write per day?
gdb
Wow, so I can be four times as efficient if I write:
while (1)
{
cout }
rather than:
while (1) { cout
And since we all know that whitespace doesn't make a difference in C/C++, I can write a whole routine or the entire program in one line if I like. Personally, as long as it does not obfuscate the readability too much, I always prefer doing things in the fewest amount of LOC possible.
This has got to be one of the dumbest articles I've read in a while.
My contribution to the GNU Fortran compiler during 1995 was to delete five characters and replace them by four other ones.
This saved a register on every DO loop and enabled loop unrolling on most DO loops.
Lines Of Codes is for Dummies.
Toon Moene.
Work - C, C++, Fortran, VB (ACKKK!), DCL
School - Modula 2, Lisp, Prolog, M68K Assembler, C, C++, bash, PL/SQL
Home - C, C++, Perl, bash
More importantly... If you are obtaining a BS in Comp. Sci., you should have the professionalism and the skills required to learn another language should the need arise. The language shouldn't matter - it's only a tool. What matters is the way you solve your program... Far too few people in Comp. Sci. understand this fact.
---
???
metrics - useless?
metrics don't tell you squat about code quality, so I guess they're pointless for a PROGRAMMER.
for a manager, however, they're useful ways to predict schedules based on past performance. it doesn't matter how subjective the "unit" is - it matters what the units are used FOR.
We didn't have labs, but it was REAL funny to see how uptight some of the students were!
a bad programmer needs more lines of code to do what a good programmer can do more elegantly and efficiently with less lines of code.
:-P
using LOC as about as useful as measuring the number of kilos a manual weighs to guage the quality of its content.
2cents... johnrpenner@earthlink.net
This is a well known fact. In fact, 20K lines per month is a little low for Canadian programmer, who actually have little else to do in the fall, winter, and spring because everything is frozen. In summer, their productivity drops dramatically because they are out chopping down trees, bagging beavers, and stuff like that.
Still, their code is pretty buggy. They should slow down and think a little before they start writing.
I couldn't claim more than 20,000 lines of code last year because I spent more than half my time designing the architecture of the system so other programmers with less skills could code to the interfaces without screwing up anyone else.
I did still manage to code around 15,000 lines of code on one project alone. Not too bad.
Jack William Bell
now up yours!
like frequency of carpal tunnel syndrome complaints! Hey, if you're wrists don't hurt, you're not doing your fair share!
>>Using a standard measure of IT productivity based on the number of
>>lines of code developed by a programmer per year, the study pegged
>>U.S. programmer productivity at an average of 7,700 lines of code,
>>compared with 16,700 lines for non-U.S. programmers.
So you mean the guy who was coding before I got here who used 48+ lines of code to generate a list of times in 1/2 hr increments (12:00am, 12:30am, etc) is more productive than myself, since I only used 8-12 lines of looping code?
Maybe the study is ass-backwards: maybe international coders are more inefficient than their American counterparts. Apples and oranges.
Don't worry about it. I was an intern at ms with no VB experience, and I learned it as I went along..
So american programmers write tight code. So?
What?! Only working "office hours"? I bet those coders are taking off at the same time their boses do. What are they trying to do? Have personal lives? Those bastards!
Get back in position. Re-fasten those corporate chains. Code! Code! Code!
Say... when will the study come out pointing to how much damage OSS has done to code productivity? "Yes... well, before all this 'Open Source' stuff, my people worked long hours on the job," says Paul H. Bosse "But then they found progects they enjoyed doing on their own and insisted on this thing called 'personal time' to work on them... its killing us."
.se = Swedish
Nobody (except maybe a few sicko's) write that many lines in ASSEMBLY. However, writing more than 20.000 lines of code in a YEAR is normal. I'm still in high school and have written over 7500 lines on ONE project.. but I estimate my total number of lines to be well over 10.000. This is all plain C code with (too?) few comments.
Java rocks! But then, I teach a Java class...
If you knew more, then you would know that Java doesn't rock at all. In fact it's one of the worst object-oriented languages to come out of the 1990's.
In my everyday breadwinning position, I have a series of active server pages that connect to a oracle database that sum greater than 20000 lines.
I think 20000 is a achievable goal for a couple of weeks.
I corrected xxxx lines of my previously written code last year
My most productive days have resulted in net negative LOC!
Amen! I'm constantly amazed by how many programs I run into (not written by me, of course) that can be improved by deleting large parts of them...
Or C++ programs written by people that don't seem to be clear on concept of OOP (Like the case where somebody created 3 absolutely identical classes by block copy... I replaced them with a single base class with 3 trivial subclasses.)
more != better, just like motion != progress
1 the return key is for lusers
Exactly!
If I leave at 5:00, and come in a 8:00, but all the other workers come in at 9:00 and work until 7:00...then go home, and work some more, who is the jerk?
I must be...because I'm compared to them.
Does this make me a bad person because I don't live for my job?
Is this the future we're all working toward?
If you were not so self-centered you would know that computer services and custom software developpement is very strong in France... they even buy back US competitors.
Oh? Which OOP languages developed in the 90s are better, then? Be sure to state the criteria by which you judge "better." C++ may be a more useful language due the sorry state of javas implementation at the moment. Does that make it better? Certainly not cleaner.
Delphi is much better than VB, and it is so close to C that once you know Delphi you can learn C++ pretty quickly. Beside it's much cooler to make a first "hello world" in a nice UI than with one of those boring printf.
Microsoft tried to kill Delphi by all means but VB has never been able to come close to it.
Try Pascal. Same as C but you get the choice of NOT use pointers if you don't want to (and usually the less you use pointers the less you have problems with them :-)
The difference between O(n) and O(n^2) is in no way 2 days - "a fraction of a second".
Duh! Wow, there goes everything I ever learned...
Think: if, let us say, program #1 takes 100,000 operations and accomplished this in a second, program #2 [O(n^2)] would take 100,000 seconds, or about 30 hours.
Remember, too, that the original poster said that the 'heavy coder' did not spot ANY algorithmic optimizations -- which implies that that algorithm ran in O(n^3), not O(n^2).
Great post! If you are looking for a job, check us out at http://www.perseus.com/ and drop me a line:
jhenning@perseusdevelopment.com
Regards,
Jeffrey
While everyone's having fun bashing LOC, which
is ridiculous, yes, I have to say that I'm on several
mailing lists for freeware projects (active in
only one at present) and a surprizingly disproportionate
number of the contributors are not American.
It would take more than just a grep through
source trees for e-mails to really answer the
question, but I have a hunch that less Americans
participate in freeware per capita.
-- An Anonymous American Coward
Wow. What an incredibly ironic comment.
This is just another attempt to justify bringing more foreign programmers into the US and send more work overseas to reduce the skyrocketing salaries of US programmers. You can generally pay them less and if they fill demand here, you can pay US programmers less. Supply and Demand.
LOC is worthless as a measurment of productivity. Perhaps US developers spend more time writing documentation, making the code more supportable. Maybe "more" US developers are using superior tools and need to write less code to provide the same functionality.
If US programmers are so bad, why does the US continue to LEAD the world in software. Sun (Java), Microsoft (sorry!), CA, IBM, Oracle, Novell, etc etc, all US companies.
As a professional programmer I can say that report is useless. Anyone who rates a programmer by the lines of code written is a fool and obviously not a programmer. What about how many times the code needs to be fixed or the complexity of the code. Does a journalist get rated by the number of sentences they write. Of course not. I also can not beleive slashdot put up a poll! The polls here are so unreliable and then they do not even attempt to distiguish American and International programmers. Thanks for feeding the stupidity.
A quick run of 'wc' indicates something on the order of 67K raw lines totaling about 2 megabytes of Perl in my current project - which is a bit under a year old. It isn't the only thing I've written this year, either. I would guess the total at well over 100K raw lines.
I need a vacation....
@work : C, ksh, awk, HTML (big deal)
@school : java, C, C++
@home : C, perl (cgi), HTML
Did you ever think to read the article?
The survey was performed by interviewing IT people. Presumably the IT people came from different countries and nothing was said that could show that IT people from different countries have the same standards for defining lines of code.
Hey, those looks like the comments required by my CS dept. classes.... You been reading their style standards?
The readers of slashdot have written in the last year at least 50 million lines of code (together)!! How does it compare to the total code in windows? Total code in the linux kernel?
Er, maybe that's because you're taking 211. Real systems take time to design, test, and debug.
with the exception of c++ if you can call that object-oriented.
I don't know about LOC, but the difference would be he is writing for reuse and would be "valuable" in a corporate programming environment where teams of people work on projects.
You would be more valuable as a Sysadmin, hacking scripts to get work done. These scripts don't have to be reused (for the most part).
In his case, the team would have a optimization programmer who would take his code and make it efficient and then they would add his block of reusable code to the library.
AC
Same here.
I'm british and Ecuadorian.
See header.
You never ovbiously used NeXT's.
Dude, who gives a fuck?
Why don't you tell us what you were doing so we can make a judgement of your apparent worth. There could be an obvious log N optimization to what you did.
Besides, its not a bid deal to be a better programming than everyone in your CS classes in college.
The first programming lesson you learn is how to print "Hello World" on the screen five times. The second lesson you learn is how to use a loop to do it in a three lines of code.
And then you learn more and realize the loop is just baggage and makes it slower.
Perl 1 line
G3 processors are faster than pentium 2, and 3. On top of that, they can't even make the fastest pentium 2s, or any 3s, for laptops which a lot of people use. What good is bragging about a fast processor if you can't put it in a portable machine. Just my 2 cents.
oh great. i can't wait until the sarcasm-impaired PHBs get wind of that suggestion. :)
not Java for UI, obj-c for UI
My personal experience (with Chinese coders) was that they were really good with cranking out efficient code, and even picking good algorithms, but their code readability was terrible. Bad variable name choices (variable names like A1, a1, A2...), lack of structured programming, etc.
And the AWT stuff was yucky, it's still haunting old apps and applets, and Swing needs some more fixing-up.
But you need to be more specific when saying it's one of the worst OOs. I don't see that as being true at all. It's not all-object like Smalltalk or stack-happy like C++. But it's pleasant and powerful and clean-looking... just watch those anon. classes :)
Then
you
split
it
up
over
many
many
lines
#and
#don't
#forget
#about
#the
#comments
But was it efficient? For an efficient Hello World program you'll need to multithread it so that each thread prints one of the characters and you'll also need thread synchronization so that they print them in order.
hey, i work with some docs refugees.
somebody i know once spend the whole day in softice and a binary editor, and added 20 or 30 bytes to some device driver from intel (see punch line below), thereby fixing something in it. groovy. i think
(oh, yeah -- the punch line is that the device driver was for an anti-virus thing, so now we've got a copy of an anti-virus thing which arbitrarily jumps to these mysterious extra instructions . . .
Even with a lot of documentation, any sufficiently-complex project will have a much greater magnitude of actual code lines than of comments
Quite the opposite, assuming good programmers. Take for example the GNU regex code. What I've looked at was about 10:1 comments:code. The more complex the project is, the harder it is to understand -- hence, it needs more (and more detailed) comments. I'll grant that a brief, meaningful comment is worth more than five lines of gibberish where the key concept is left out, but that's a separate issue. For any given, constant quality of commenting, a more complex program needs more comments.
if you have more than one blank line at a time you need some serious help anyway
Gibberish. With at least 1024x768 resolution you can afford some extra whitespace to keep things clear. I find it helpful and I'm not the only one. You're not required to agree, but I don't need any "serious" help just because I write readable code.
Hell, while you're at it, why not use commas instead of curly braces:
if ( foo() )
_ _ bar(), baz();
. . . there's an old dos port of sed 1.5 floating around that's infested with that kind of garbage, like so (I'm not even sure what this will actually return):
return (*++cbuf = '\0', any);
it's got many names on it. ESR's is one of them, but there's no reason at all to blame him specifically.
Or did you just not bother to read the entire message?
The stupidity of humans never ceases to amaze me.
will get you a programming position. Well, lemme take that back, knowing how to turn on a computer will be suffice.
mit
anybody know offhand what the textbook was called and who wrote it? i borrowed a copy once from somebody and, fool that i am, i gave it back.
(just to clarify this, i never went to mit. not only wouldn't they take me as a student, they won't even let me drive past the place.)
baby.
it is so close to C that once you know Delphi you can learn C++ pretty quickly.
Um, you can learn most of the syntax relatively easily. It's a very different language, though. You can, essentially, write ObjectPascal code in C++ and lose out on a lot of benefits. I went at it the other way: When they handed me a copy of Delphi, I wrote C code in ObjectPascal for a while, then we dropped Delphi (it's a really great tool, but we were all C/C++ bigots, not entirely to our credit) and I started learning C++. It was weird. It took me the better part of a year to really grok C++.
Delphi is really cool, but I'd have a hard time going back to a language that won't let me do default arguments, multiple inheritance, operator overloads (especially cast operators, damn I love those), copy constructors, blah blah blah. (If any of those things *can* be done in Delphi, for God's same flame me and let me know! Get the word out!
uh.
yeah, i know it's irrelevant. sue me.
or some damn thing, i never can remember unix shell quoting rules or what it does (if anything) with backslashes.
you know what i mean anyway.
perl is way overkill for that.
. . . that the poor dumb bastard was probably writing in an interpreted language.
:)
I've rewritten code before, with a good 20:1 expansion ratio, because the original code was too clever for its own good.
Heh. I hear you. I sometimes write annoyingly clever crap (i write in C++, which allows godawful grand opportunities for silly clever shit that's totally unreadable), but then I comment it out and write the same code readably -- but I leave the commented crap in so the other guys I work with can see how clever I am
The "optimization" thing holds less and less water as the years pass and optimizers get smarter. It's real damn rare that you're actually gaining any performance by making the code goofy, and in modern (GUI, anyhow) programs, there are a lot of places where optimization for speed is silly anyway. Save it for the tight loops.
The problem with the survey is that I believe the United Steates has a large number of "casual programmers" who program just to try it out, or as a hobby, proportional to other nations.
... The one with fewer lines of code will invariably:
* Take less time to create
* Require fewer programmers to create
* Have fewer bugs.
(Derived from _Measures for Excellence_, by Lawrence Putnam et al.)
The better the programmer, the more sophisticated his abstractions, thus the more compact (and effective) his code. Compare:
Program One: Novice programmer
System.out.println("1");
System.out.println("2");
System.out.println("3");
System.out.println("4");
System.out.println("5");
System.out.prnitln("6");
System.out.println("7");
System.out.println("8");
System.out.println("9");
System.out.println("10");
Program Two: Experienced programmer
for (int i=1; i=10; i++) System.out.println(i);
Program one has 10 SLOC, program two has one. Number two is easier to change, has fewer bugs, and took much less time to write. (The
Bottom line: SLOC is a pathetic measure of programmer productivity.
Well, besides Technion, I don't know any other good schools there (maybe in Turkey? I have no idea).
Lack of money, strict cultures, etc. may explain this.
To judge productivity by LOC is stupid. I write twice as much code as my coworker because I have only been coding a short time and my code is inefficient.
:)
But i'm getting better
+ Venture Capital and so on.
- Stupid culture. Greed. Linear personalities.
Also, many people in the States (well, probably not NY) get BORED on weekends (add to that being scared to get out of home/car/mall/office), so it's better to just work (probably for yourself).
I'm an American programmer, and I work harder than some, and less hard than many. But I do good work. My work is quality. And right now, I'm off to Hawaii for three weeks of debauchery thanks to my *FAT* American paycheck! Yeeeeehaaaa!
PS. narf!
I was going to say the same thing, having had a similar experience. The previous programmer was a real code churner, and cranked out large amoiunts of semi-working code. But, he almost never tested it in any robust way, and I'm rewriting it all because it was so unmaintainable and buggy. He was a cut-n-paste programmer; rather than create a function and parameterize the variances, he'd make endless if/then statements with dozens of lines of dupllicate code changing a few constants or the variable names (almost always globals). If he made a change, or a bug fix in one section, it rarely propagated to other sections...
I'm rewriting his C code in Python, which is MUCH quicker (he was clueless about the intricacies of pointers, BTW), and allows me to easily test *everything* as I go along.
A programmer turns out 2 lines of code per hour, on average.
What is assumed - is that this is production quality code.
Mark
When I started my current job I worked with a guy who would write three times as many lines of code in a day as I do. The problem was the quality. He would write a lot of code, but not design or test the software well. As a result he produced a lot of poorly written software. Because he got so much done he got the attention of management. Was moved from one high priority task to another. Eventually the customer complaints with his products started to catch up with him. He did what most people do at this point. He found a new job and left the mess to for someone else to clean up. I spent many months working on software he had written. I added a few new features, but spent most of my time figuring where the bugs were and rewriting the uncommented, poorly written code. The code is considerably shorter now. Probably 60% to 70% as long as it was, but much more stable. If you consider the length of the program, I was probably negative on lines of code for several months.
I don't want to give the impression that he was lazy. He consistently worked 56 to 60 hour weeks. I work more on the range of 40 to 45 hours, but in the end, I'm a lot more productive.
If you pulled down your pants first, that would avoid the warm squishy feeling to begin with.
You're both right. And you're both wrong.
Most americans are arrogant little f_cks. We all know this. The majority of americans are also IGNORANT arrogant little f_cks. And american workers are not especially more productive; american industries and companies are, generally through more efficient use of technology and what labor they can get.
Speaking as someone who works with many, many foreign nationals in various fields, however, I believe I CAN state, with as much accuracy as my above comment, that the "stupid generalization" is closer to the truth than otherwise. There are plenty of honest, hard-working non-americans, just as there are plenty of hard-working, intelligent, humble americans. The main reason that non-american workers get such a bad rap is that they are, in general, not as good, primarily because the majority of the best and the brightest go to the US for education, get a job, and end up staying.
Grow up, guys. The world is not perfect, neither are the people in it, and who gives a flying fuck at a rolling donut WHAT some idiot reporter thinks?
There are several reasons why LOC isn't an accurate measure of productivity. My particular favorite is the fact that a line of code isn't the same from one language to another, or even from one programmer to another.
Consider this example:
(*In Pascal, in a commonly used style*)
if a b then
return a
else
return b;
/*In C, in another commonly used style*/
return ((a
Hmmm. 4 lines of code, or 1? The action is the same, but the LOC count isn't.
Consider also graphical development tools such as Delphi. How do you measure LOC for a button dropped on a form? Further, do you count the automatically inserted code as part of the LOC measurement, or do you (try to) only count what the developer had to write?
There are several reasons why LOC isn't an accurate measure of productivity. My particular favorite is the fact that a line of code isn't the same from one language to another, or even from one programmer to another. Consider this example: (*In Pascal, in a commonly used style*) if a b then return a else return b; /*In C, in another commonly used style*/ return ((a Hmmm. 4 lines of code, or 1? The action is the same, but the LOC count isn't. Consider also graphical development tools such as Delphi. How do you measure LOC for a button dropped on a form? Further, do you count the automatically inserted code as part of the LOC measurement, or do you (try to) only count what the developer had to write?
I think you mean:
for(i=1;i=100;printf("%d\n",i++));
>Based on this comment I can conclude that you are >a f_cking moron, as only a moron would arrive at >such a hasty generalization. Based on my >exposure to Americans I can conclude they are >arrogant f_cks, convinced of their own >superiority.
We are. Because we routinely kick the shit out of the Europeans.
>But I have realised that everyone is >different, and while a system may be broken the >people usually are not.
what system is better? Did the Soviets code more lines? I bet they did. Since all they had to code with was old stolen COBOL machines. You're an idiot.
while we are getting int line count arguments... what about characters?
1234567890123456789012
cat foo.c | tr -d '\n'
perl -pe 'chop;' foo.c
albeit that the shell way is quicker.
There is a concept of "software metrics" in which
standardized measures of productivity are attempted. It's slightly less of a crock than
KLOCs. Even Mickeysoft knows KLOCs aren't valid.
Old story: A firm's telephones go down. The tech walks into the wiring closet, plugs one loosened
wire back in, hands the bill to the manager for
$150.00. The manager sputters "But you only
spent 5 minutes!". The tech says "Yeah. $1.00 for
plugging it in, $149.00 for knowing which one".
As soon as you establish a means of measuring productivity and reward it, people will adapt
their behavior accordingly. Besides, it's the lines you *don't* write - the unnecessary and
incorrect - that count. I feel for those that have to establish accountability in this, I
really do. But I wish they'd stay the heck out of the way of those who have work to do.
Finally, for the managers, which is more important, seeing the slaves sweat, or making your target? If people consistently overwork,
it may look good to someone with a football coach
mentality ("Good hustle"), but it may or may not add value. Perhaps as Yourdon notices, there's been a backlash/burnout from former experience.
It takes as long as it takes.
And that is before breakfast!
I heard that Thomas Hoffman, the author of the CNN report, writes less then 1000 sentences a year. This "author" is obviously a slacker. Can we really trust a report from such a slacker? From now on I only read articles by authors who write more than 10,000 sentences a year. I don't have the time to read trash spilled out by Thomas Hoffman and other slacking pamphlet writers.
Good day!
I'm not from the US, I'm Welsh, and I'm working in Switzerland at the moment.
.c, .h and .pl files from *one* of a number of projects I worked on (by myself) last year came to >23,300 lines.
:)
:)
I thought I had a lazy year last year.
A brief line count of the
Normally my average for employed work (i.e., not counting pet projects) is about 40,000 lines per year. That's after deletions. I'm not keen on cutting & pasting.
It's funny. I always think of myself is exceptionally lax at work. I'm hardly ever there, many days I don't write anything at all, and I spend most of the time reading Slashdot and other sites
Guess I should slow down
-- Jamie Lokier
what was i thinking using cat?!?! the above is even shorter than your perl! bwahahahahaa!
the awk below comes out one character longer, dammit -- and "awk" is shorter than "perl", too, so even with an unfair advantage it loses!
1234567890123456789012
cat foo.c | tr -d '\n'
perl -pe 'chop;' foo.c
tr -d '\n' foo.c
awk '{printf $0}' foo.c
for(i=1;i=100;printf("%d\n",i++));
You're aware that that's never gonna exit, right? You're assigning 100 to i on each iteration instead of evaluating i. The assignment expression evaluates to true, so it'll just print "100\n" until hell freezes.
more like this:
for ( i = 1; i != 100; printf( "%d\n", i++ ) );
or better yet . . .
int i = 100;
/* the second expression is evaluated. */
while ( printf( "%d\n", 100 - --i ), i );
or, finally, on those four-martini-lunch days:
char s[] = "00";
for ( s[0]='0'; isdigit(s[0]); ++(s[0]) )
_ _ for ( s[1]='0'; isdigit(s[1]); ++(s[1]) )
_ _ _ _ puts( s );
Scots, Brits, Indians, all of 'em. I don't know where the hell East Angola is, but I bet they talk funny there, too. The French are the worst, though. I swear to God I spent a week in France and when they babbled at me, it didn't even sound like English! No way could I understand a word of it. Just a lot of "Unh, munh, meu meu" gibberish, and all of it straight through their noses. Now what the hell is that supposed to mean?! The pretended they didn't understand me, either, no matter how loud I yelled at the dumb bastards. After a while I got the idea that if I grabbed 'em and shook 'em a bit, maybe they'd tune in, right? So I tried it, and they just ran away! Cowards! Except for a couple guys tried to hit me and I had to kick their ass. France, what a shitty place. Maybe if they ever learn to talk I'll go back, but until then I have better things to do than put up with a bunch of wine-slurping, cheese-nibbling pansies mumbling at me through their f*cking noses.
what is the problem with this exactly
In the course of a couple of average weeks during the early stages of a project, a good programmer may very well generate as much as several hundred lines of airtight, debugged, consistent, documented code which integrates well with the rest of the project. This assumes that the interfaces between modules are clearly defined, consistent, reasonably complete (they'll never be entirely complete at this stage), and never violated. A good OOP language makes this degree of logorrhea possible by minimizing the points of contact between different modules, and eliminating entirely any contact between the implementations of different modules. (A good programmer using that OOP language knows when to bend the rules, too (not bloody often
20,000 lines of code in a couple of weeks? I don't know "active server pages" well, but if you need to write 20,000 lines of code for them, they're sure as hell failing to gain you whatever ease and simplicity you were hoping for when you chose to use 'em. And whatever you did, I find it very hard to believe that it all works as advertised if it was hammered out at that rate.
I'm a UNIX admin, I mostly program in Borne Shell and awk. Sometimes perl and a little C is needed as well.
Dammit, I thought slashdot didn't eat angle-brackets in titles. Shit. There should be a left-redirect there, and another one where the same command line appears in the text of the post.
Sorry.
Another stupid coding trick:
"Henry Spencer at the University of Toronto wrote a retargetable assembler completely as `awk' scripts. It is thousands of lines long, including machine descriptions for several eight-bit microcomputers. It is a good example of a program that would have been better written in another language."
-- Edition 1.0 of GNU's `AWK Language Programming'
I'm a test engineer.
I took someone else's program of about 8000 lines, cut the amount of code used by more than half by more efficient coding (is this new lines of code), added some extra features (extra 1K lines of code) and used the resulting module(s) as part of 4 programs (say 500 lines individuality in each).
Did I write
a) no lines of code (I hacked someone elses)
b) 2000 lines of code (the 500 individual bits)
c) 7000 lines of code (4*500+the 5000 common)
d) 22000 lines of code (4*500+4*5000)
e) some other figure ?
I'd actually go for the higher figure myself, not because I'm bragging, but because I saw the reuse would save my fingers which made me a better programmer than the other guy....
I can name a small software subcontractor (three Employees, 2 who actually Code) who program circles around aome of our staff programmers. the reason? simple, they would spend most of their time interacting with the customer, developing an accurate specification for the projectbased on the customers problem. In the process they are able to educate the customer of the programs potential or limitations, so the customer does not have unrealistic expectations. They also take a lot of pride in there work and Debugg their code vigorously in a variety of environments, and provide complete documentation .
Conversly, our staff programmers seem to half listen to the customer, hammer out some code,(no time for documentation) test it once in runtime and assume it will work on 95/98/NT.
The subcontractors generally take about 50% longer for a solution, depending on the scope of the project. But I've never had a problem getting a signoff. As a project manager I could give a Sh_t about the # of LOC if a project is on time, within budget and the customer signs a check when invoiced.
groovy.
A = A.
A widget is a widget, a line of code is a line of code. They're the SAME THING, okay, stupid? The SAME THING. A equals A. Don't waste my time whining about any mystical, liberal/religious wrecker crap about how they're not, because they are. A equals A, period. End of story. If A is good, then 10 * A is ten times as good as 1 * A. If A is bad, it's just the opposite. It's that simple. If you can't handle that kind of simple arithmetic, you have no business being a programmer.
Period. End of story.
Yes! At work we do like so . . .
if (...)
{
. . .
}
. . . and it's better to be consistent than to be right when you have a lot of people working on the same code, but dammit, when I get home I do it properly. Also sometimes at work I write gawk scripts, and gawk in some contexts (or all?) *requires* K'n'R indenting (hmmmm . . . the 'K' in awk is also the 'K' in K'n'R -- coincidence!? I think not.) so I get to do awk code the way God intended.
Incidentally, GNU indent doesn't seem to have an option to put spaces around argument lists, like so:
foo( a, b );
as opposed to
foo(a, b);
. . . am I just missing something? Or must I hack the damn thing . . . Urrrggghhhh . . . Damn, it'd be worth it, though. By the way, God also wants us to put spaces before the left paren in if (), for (), while (), and switch ().
:)
Change '\n' to \\n and you've saved yourself a keystroke and since the seek time from the \ key to the \ key is zero, you'll see a speed increase greater than the average time of one keystroke.
Nobody can program more efficiently than the Ethiopians.
Industry groups sponsor bogus studies like this so that they can attempt to generate support for the H-1B visa program. If they could they'd move all software development to the same countries where they moved the sneaker factories. They can't, so they want to move the workers here.
PROGRAMMERS OF THE WORLD UNITE!!!!
Join the Programmers Guild (www.programmersguild.org)
Together we can fight this industry propaganda.
Say, that would be an interesting poll question. Is there any way we can select more than one option in the poll?
Sure, just by replacing INPUT type=radio with INPUT type=checkbox
Wow, a real live american moron! And I get to flame him all by myself? Cool.
All right you little F_ck, you obviously haven't learned much about life if you still believe that the capacity to deploy force defines superiority. That's something you learn in grade school: the bullies get the lunch money, but they have no friends, and no brains. Same with Linux: M$ might get the money, but they get no respect.
As they say in my country: "Va te faire foutre petit con."
"violence is the last resort of the incompetent".
Wow, a real live american moron! And I get to flame him all by myself? Cool.
All right you little F_ck, you obviously haven't learned much about life if you still believe that the capacity to deploy force defines superiority. That's something you learn in grade school: the bullies get the lunch money, but they have no friends, and no brains. Same with Linux: M$ might get all the money, but they get no respect.
As they say in my country: "Va te faire foutre petit con". Go to hell.
"violence is the last resort of the incompetent".
(from Isaac Assimov's foundation trilogy (Hardin's moto I believe)).
You're right! Damn I feel dumb. That's too cool. It also knocks another byte off the tr command line as opposed to the perl one (not even considering what a pain it is to type "perl", which needs the little finger for the 'p', and then doesn't alternate hands (unlike such classics as rm, ls, mv, cp, ps, and even dir).
A lot of work went into it. It's a damn nice troll. I think it deserves at least to be read, don't you? I really don't see how I can go on writing such solid, high-quality trolls (note for example the narrative voice transmogrifiying "East Anglia" into "East Angola") if I don't get the sort of artistic validation that comes from a few responses. I'd prefer snarling, knee-jerk flames, of course, but I'll take good-natured laughter if that's all I can get.
Why is f_ck any better than fuck? Is f_ck any less offensive?
okee doke... since i am an arrogant american f_ck, i'll go get in my BMW, drive to my home in the suburbs, watch tv and cheer for the Americans in Yugoslavia, complain about how even though we have enough Industry to go around American industry is moving overseas, polish my handgun and feel the pain of "white man's burden"(i've heard ALL of these stereotypes of Americans before).... please... give me some credit.... in a land of over 280 million people you cannot assume we are all arrogant asses trying to enforce the "big stick" policy of Roosevelt... the problem is that the ones with nothing to say have the biggest mouths... you ignore the radicals and you hear the majority...
What you are forgetting is that the results of this study were pre-ordained. India the well-known center of high quality software [Chorus of Laughter] was going to come out on top no matter what. The selection of LOC as the measurenment was to produce the predetermined result.
The reason India was made to come out on top is that India is the largest supplier of H-1B visas. Industry groups want their cheap programmers so they pay for studies like this one that show there is a BETTER (not cheaper) labor pool in India that we could take advantage of.
Fight back: Join the Programmer's Guild www.programmersguild.org
You're wrong. The authors were not idiots.
In this giant discussion most of you folks have missed the point of the study: To justify importing cheap foreign programmers. Since most H-1B programmers come from India, the funders of the study need results that show they are importing quality programmers.
The report is indended for members of Congress who don't know a line of code from Morse code. They are going to see a summary that supports the effort to increase the number of imported programmers.
Fight back: Join the Programmer's Guild
www.programmersguild.org
Yeh right. 115,000 people a year with rare skill. Did you read the report in the LA Times a couple weeks ago about the company that was fined (a whopping $3,000) for paying employees on H-1B visas 1/3 the market rate.
Oh yeh, these employees included such high-tech and hard to find positions as an accountant and sales rep.
It's not cheaper to open up an office in India. Many US companies have tried and the results have generally been poor. If it's simple, going to India sometimes works. If it's complex....
Getting an H-1B easy. Total cost, including legal fees (all but $500 of which you can get the employee to pay) is about $1,500. There are
bodyshops that specialize in supplying H-1B labor so you don't even have to do the work yourself.
An Rubin is a whore. Put some pennies in his hand, turn the crank, and he will produce a report that says anything you want.
Yeh, but it's bullshit with a purpose.
That purpose is to justify importing Indian programmers to the US.
I don't know where you are getting your information from, but it's simply wrong. The purpose of the H-1B program may be as you say, but explain why that vast majority of H-1B holders come from low wage countries rather than those known for developments in CS and Engineering and the Sciences?
There is no requirement to prove that you could not find people before hiring H-1B's. In fact, it is perfectly legal to fire Americans and replace them with H-1B workers as a cost savings measure. (This has been done many times, at least two companies in NJ fired more than 100 programmers at once in an attempt to get H-1B cost savings.)
The issue is not the number of lines of code. CIO magazine ran relative lines of code numbers a couple of years ago and the rankings were Canada, US, ... and India at the bottom.
The problem industry group were facing is that they complain about not being able to find qualified programmers. And yet, when the bring programmers into the US, the vast majority were coming from countries with low productivity. They needed a study that shows the import programmers are actually coming from high productivity to show to congress.
Read what the author of the "Slacker Report" has to say about counting lines of code.
http://www.hrubin.com/headline/mistake.html
That's my name, don't wear it out. And I only code for donuts. I've written 20k+ lines this year. Imagine the donuts. To impress employers I have a little script that just adds a lot of white space and meaningless comments. Those of you with the Dilbert Desktop Toy program might be familiar with it. "Process: Provides object model code with key instantiation data for persistent storage and authentication." Few K lines like that and they stop reading and just trust you.
It's raining donuts again.
It would be interesting to see how many ci or commit commands were done per year per programmer.
What about when the power goes off for months on end? (Like it did last year)
:)
LOC becomes non-existant
I would think if American softwares can do the job in half the lines of code, it just means that the American programmers are that much smarter.
Now, just because NT is 30 million + lines of code, is it better than Linux? I think not. The more lines of code means more bugs and less efficiency.
IBM used to pay their programmers for lines of code.. This is the most idiotic thing I've ever heard. Writing more lines of code doesn't make you productive, it makes you a poor programmer.
-AC
I work for a Japanize company with a division in the US. For several years we used to hear comments that Japan company programs had a higher LOC throughput and less bugs per LOC.
This was all very true based on the LOC counts that each side tracked.
Finally someone decided to look in to how each side determined what 1 LOC was. Turns out Japan pretty much counted any line in a file, including comments, were as in the US we were using a much stricter definition, closer to counting each ";".
After recalculating it turned out US side had a better bug-to-LOC ratio with slightly less LOC (just means higher performance code as well).
This is bullshit people. Plain, simple, and unadulterated bullshit. I've been out in the RealWorld (TM) since '91, so I'm speaking from experience here...
LOC is absolutely positively the *WORST* means of evaluating programmer performance. At times, both I and my colleagues have had *NEGATIVE* lines-of-code-per-week values. This stemmed from another department linking LOC to bonuses, encouraging their programmers to use cut-and-paste programming. After all, why call the same routine twice when duplicating that routine will increase your bottom line...
Needless to say, that department's project became, in a matter of months, completely unmanageable and uncompletable. And there was a great deal of celebration in that department when the client canceled their contract without suing us...
Hint: If you see this happening at your company, it means: Circulate your Resume NOW!
Another factor that may have been completely overlooked is what American programmers are doing besides writing code. How much time is being spent in meetings, demos, support, answering the phone, systems administration, debugging third party software, installing/configuring *ANYTHING* made by microsoft, etc. Perhaps more importantly, how much time is being spent in **DESIGN**. Since, with Object-Oriented approaches, the vast majority (more than half) of your time better be spent in design. If not, well, you're in for a lot of pain, suffering, and cost overruns...
Finally, what are working conditions like? Modern offices are *NOT* optimized for writing code! They are optimized for managing underlings!!
There's a test that I like to give managers. I ask them to count backwards from 100 by 3's. Then, after they're down to about 91, I start calling out random numbers between 1 and 100. It's a rare person who can make it to 70.
Then consider the cubicle that I was located in a while back. The partitions were transparent to sound. And the fellow on the other side of my partition was trying, very hard, to switch careers and become a sports agent. On my other cubicle wall was the hall corridor, right where it met the elevators for the floor. Across the hall, about 2 meters away, was the kitchenette. Which contained the coffee machine, where everyone went to socialize. Which was difficult for them to do because the copier was also located in the kitchenette, and they had to talk quite loudly to be heard over it. Just to insure that a quiet moment would never occur, purchasing was located in the next cubicle bay down the corridor...
I find that the same part of my mind that I use to write code is also used to process speech. But speech has a higher priority interrupt. My productivity fell through the floor...
Nowadays I work for a different company. And, do to similar problems, I now telecommute from home, where my productivity is much *much* higher...
The problem with theses US vs. the world type polls is difficult to eliminate. US respondents, especially engineers, tend to be relatively honest. In most other countries, and I know I'm going to get a lot of grief for this, common respondents tend to tell bald-faced lies as naturally as they bribe their local govt officials for favorable treatment. Or the books are cooked by officials who instruct respondents to give "offically correct" answers. Witness the numbers from the Japanese educational system of the 80s. Entire classes of students not counted in the stats if they weren't considered "acceptable".
In addition, lots of programmers who aren't US nationals work in US software companies. Does their productivity magically decline the instant they hit our shores?
I am biased, as I have worked on many projects with offshore programmers, and have never seen any value gained from the practice. On the contrary, it has always been an expensive process, resulting in the offshore code being thrown away and reimplemented locally at greater expense, partly because the deadline could not move even though our foreign counterparts wasted most of the schedule.
Measure twice, cut once.
Yes, I went back to school this semester and I have noticed a significant difference in LOC and bug counts between me and compsci students, and especially me and non-CS types who are taking intro computer courses.
In general, 100 lines of my code is worth about 300 lines of the CS student's code, which is worth about 1000 lines of a tyro's code. And not surprisingly, the people who write the shortest programs also write the least buggy programs. Brevity demonstrates an understanding of the problem, and understanding the problem means you are unlikely to introduce bugs.
Code is a liability, not an asset. The more source code you write, the more bugs you will encounter, and the more problems you will have to fix later. (e.g. Y2K).
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.
Author unknown, sung to the tune of The Beatles' "Let it Be".
When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom: "Write in C."
As the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers
"Write in C."
Write in C, write in C,
Write in C, write in C.
LISP is dead and buried,
Write in C.
I used to write a lot of FORTRAN,
for science it worked flawlessly,
Try using it for graphics!
Write in C.
If you've just spent nearly 30 hours
Debugging some assembly,
Soon you will be glad to
Write in C.
Write in C, write in C,
Write In C, yeah, write in C.
Only wimps use BASIC,
Write in C.
Write in C, write in C,
Write in C, oh, write in C.
Pascal won't quite cut it,
Write in C.
Guitar Solo
Write in C, write in C,
Write in C, yeah, write in C.
Don't even mention COBOL,
Write in C.
And when the screen is fuzzy,
And the editor is bugging me,
I'm sick of ones and zeroes,
Write in C.
A thousand people swear that T.P.
Seven is the one for me.
I hate the word PROCEDURE,
Write in C.
Write in C, write in C,
Write in C, yeah, write in C.
PL1 is 80's,
Write in C.
Write in C, write in C,
Write in C, oh, write in C.
The government loves Ada,
Write in C.
----
Open mind, insert foot.
I worked on a COBOL-to-C conversion several years ago, using Microport 286, of all things. There were two of us, the other programmer consistently wrote about five pages of code a day, I usually delivered about 1.5 to 2 pages. After about one week there was a confrontation about the disparity. I replied that my code compiled, ran, and worked as well as could be expected with stubs substituting for missing functionality. I asked the other programmer if she could make the same claims for her code--she couldn't. Did this make any difference? No, I was outta there.
About four years later I learned that one of the best C coders in our part of the world came in right behind me and met the same fate--last I heard, he was working for the Deathstar Company in Jersey--now I don't feel so bad, but at the time I was really pissed.
"Lines Of Code" ignores issues of efficiency, complexity, suitability for purpose, and stability. If LOC were any measure of quality, Windows would be the best code known to man. LOC is a bad metric that should die an excrutiatingly painful death.
slashdot broke my sig
Paying programmers by the number of lines they produce is only slightly less dangerous than paying firemen by the number of fires they put out.
The only thing worse would be paying them by the number of bugs they fix.
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.")
$ cvs diff -ub -D'1 jan 1998' -D'31 dec 1998' | diffstat | tail -1
57 files changed, 8940 insertions, 6816 deletions
So, did I write 8940 lines or (8940-6816) = 2124 ?
Actually, since some lines were rewritten more than once I wrote far more than 10k lines during the year and deleted far more than 7k (plus I workied on side projects too). But, of course, diff thinks a change of 1 character is a change of that line.
Now when I talk about rewritting code I don't just mean getting rid of the bugs. The versions that I check into CVS are already debugged, so (usually) only contain little bugglets. What I'm talking about here is things like the changes needed to incorporate new features or redesign of some internal data structure.
If you consider the 1999 model of a car to be 1% different from the 1998 model do you then say that the engineers were working at a rate that would take them 100 years to design a new car?
--
--
All material not otherwise attributed is the opinion of the author or a typo.
$ cvs diff -ub -D'1 jan 1998' -D'31 dec 1998' | diffstat | tail -1
57 files changed, 8940 insertions, 6816 deletions
So, did I write 8940 lines or (8940-6816) = 2124 ?
Actually, since some lines were rewritten more than once I wrote far more than 10k lines during the year and deleted far more than 7k (plus I workied on side projects too). But, of course, diff thinks a change of 1 character is a change of that line.
Now when I talk about rewritting code I don't just mean getting rid of the bugs. The versions that I check into CVS are already debugged, so (usually) only contain little bugglets. What I'm talking about here is things like the changes needed to incorporate new features or redesign of some internal data structure.
If you consider the 1999 model of a car to be 1% different from the 1998 model do you then say that the engineers were working at a rate that would take them 100 years to design a new car?
--
--
All material not otherwise attributed is the opinion of the author or a typo.
Right now I'm deploying a tiny Perl program that monitors all the servers at work and sends nastygrams when they go down. It's running on two servers at my location and once I get this little Linux system built, it'll be running on one server downtown. Most of the web-related things here are also in Perl. The only other language I really use is C, to make local modifications to various daemons.
I tend to do that while I'm building parts of programs, but I delete them when I'm done. When I killed the 'blocked out' lines from my current project prior to deploying it, I noticed the line count drop by half. At least I tend to over-comment when I comment.
Contrary to the popular belief, there indeed is no God.
So where's the choice for, "Yeah, like I counted them..."
I'd have sworn I wrote less than 1000 until I counted just three programs (coincedentally the ones with GPLed source available online) and found it was around 1500 lines. Not lines of C, mind you, but for 'a that still lines of GPLed code. _Mac_ code! So that's 1500 lines closer to open source setting the tone for Mac development too :)
The ultimate 'toy language': REALbasic for the Mac. Sort of 'Visual Basic minus as much cruft as possible' with a heavy emphasis on interfacebuilding tools: I wrote 1500 lines but the GUI code I didn't have to write would have been at least 3000 lines if not 5000 :) :) :)
Also, the people at REAL software have openly stated that, given the chance to add compatibility with VB, they won't add compatibility to features that suck
Lastly, I don't count HTML as a language, and at any rate, I wrote a REALbasic program to generate my site from text and some markup, so it's moot. In all seriousness, RB will never be any good for device drivers or calculation engines, but it's at least as good as any scripting language, and by God is it quick to prototype stuff in. Whee! Also it's not really basic, just uses some similar syntax and has the reassuring name- it's quite event-driven, does thread classes, and even has a wizzy sprite engine for fooling around with games
What's wrong with :)
StaticText1.text="Hello World" ?
I dunno if this is the way VB does it, but it's REALbasic code, and it seems nice and straightforward. You drag the statictext onto the app window and set it up mousishly
I just munched up a copy of SiteBotSource.txt with 'cut lines including', and got the following ratio:
//Comments rule!
Source: 550 lines
Comments: 235 lines
This is because I needed Sitebot to work for _me_, and it calls its own routines recursively and does many strange and arcane things (if I didn't need to auto-link to a separate FX folder that's always at root level the whole thing could have been done by hand but nooooo, genius here had to come up with more complicated things to do to^H^Hwith it)
When coding weird stuff the most bizarre notions are likely to seem obvious, and then be totally inexplicable in a month. I like to be able to stop coding on Sitebot for a month, and then resume without spending hours figuring out what I was thinking....
Trusting soul, aren't you!
I always try to figure out the most evil things I can do to my programs to make them crash and burn, and if it seems possible I'll do the error checking.
Not if (2+2 = 5)
but if (application is expecting to be able to get parent folderitem for itself as a folder/directory but surprise! It's at root level out of the folder it shipped in. On a Zip Disk. Which is write protected, with one of the sectors damaged >:) )
Get it? If you don't try to kill your program in horrible ways, horrible things will eventually happen anyway, and your program will faw down go boom, probably when someone needs it most. I don't care what Linus says- he can and should make the Linux kernel an intricate perfect diamond dependent only on his own code- but when I'm writing applications I assume nothing.
If your app needs no error checking, you probably aren't letting users run amok enough. Saying 'don't touch anything' isn't okay. They need to get their little paws dirty and feel they can mess with whatever- and if they break your program's dependencies doing so, unless it's truly speed critical and you can't spare the check at all, you need to SAY what they did to break it so they can learn and fix it.
I write mostly in PHP and Perl (since a lot of stuff is web based). You should also take a look at Python and SQL. Not to mention C.
Posted by EveBaby:
Did you americans ever think that what a "line of code" is, must have been the same across the study??
American idiocy never ceases to amaze me . . .
Posted by The Trailer:
I would think that generating fewer lines of code would be a mark of excellence in this industry, not laziness. I'd much rather produce an elegant 7700 lines of code than 16,000+ lines of bloatware.
oh well.
Posted by Lulu of the Lotus-Eaters:
:-). I've had a similar experience most places that I have inherited code.
One of the other silly things about counting LOC is that it is often so much more productive to ELIMINATE code than to write new lines.
I probably wrote some small number of thousands of lines of new code last year. But I am quite certain that I simultaneously managed to delete more lines than that from legacy products/projects. Some of that was in Y2K remediation, other parts were just in regular code maintenance, version creation.
Bad programmers, or even just good programmers in too much of a hurry, will write almost the same 50 lines over and over rather than stick them into a generalized function/class; or they may simply not know that someone else in the workteam (who left years earlier) had written that function and stuck it somewhere in a different program. Also, but to a smaller extent, programmers use inefficient expressions of an algorithm that can be expressed non-cryptically (no obfuscated Perl for me) in many fewer lines.
So during my 1998 contract, I probably wound up getting paid a net NEGATIVE $10 per line of code I wrote
Posted by Lord Kano-The Gangster Of Love:
What this article may not be taking into consideration is the language that code is written in. Cobol or Fortran are languages which dictate that coders use more lines to do the same things. In the US C(++) is the dominant language. The objects in C++ and the ability to reuse those objects eliminates the need the re-invent the wheel and type those lines of code again, and again.
I keep all of the code that I've written handy, just in case I want to save 4 hours of work rewriting and redebugging a group of objects.
I'm not currently coding for a living, I do it to learn, and to accomplish simple repetitive tasks. If I had to do it to keep food on my table, I'd probably learn even more tricks to save time and get the job done faster. If these guys could get the same amount of work done while only writing 500 lines of code, I'd say all the better.
LK
Posted by Pseudonet:
Could anybody tell me what percentage of Microsoft programmers are American - this article could explain a few things.
From
A man how writes barely 1000 lines a year
Posted by Zero G:
This is so strange. I was talking about this around 12:30 this morning, one hour before the post. The only exception is that I was refering more to (both corporate & private) windows programmers. I HATE all this visual crap. (Dos rules!) I even run an open source site.
Posted by Zero G:
I program in a lot of different languages.
I do mostly C, but I use other languages as needed.
Posted by Paul Holden:
The difference between O(n) and O(n^2) is in no way 2 days - "a fraction of a second".
Posted by LOTHAR, of the Hill People:
of course I don't write many lines of code.
I do however, reuse a great deal of code. I spend more time designing than programming so I don't have to write large amounts of code, re-write, or patch.
Posted by The Merry Misanthrope:
If it's hard to write, it should be hard to read.
Posted by The Merry Misanthrope:
If you know how many lines of code you've written in the last year, you've got way too much time on your hands. Go be more productive, weenie boys!
Posted by Reitzel:
Hmm. I notice that this code has NOT ONE SINGLE COMMENT. Terrible practicum, well on the way to Write-Only Programs.
Some more salient questions about code: How many _totally_incompatible_except_MicroSoft() function calls did you use? How many global variables changed in every function you ever wrote? How many ridiculous fpszqhPrefixToVariableName did you use? And finally, how many of those lines of code were (gulps back bile) VisualBasic...
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.
As you write this, the over-the-hill threshold has dropped into the upper 30's.
... very razy
Razy americans
Wansu, th' chinese sailor
If you're so valuable it should be trivial to get a job elsewhere for a reasonable salary. Decent programmers actually *are* in demand, you just have to force the issue.
Remember that what's inside of you doesn't matter because nobody can see it.
Okay, so I don't know every programing language that mankind has ever invented. But anyone who can get a CS degree should be able to pick up any language needed in just a few days. It will take months to learn all the tricks, but in a few days you can be productive, and a in a week nearly as good as the seasoned veterans (with the same expirence as you).
The important part of programing is algorythims, data structures, and the expirence to know when to apply them. The skills from one language translate to anouther easially.
I have on several occosions sat down with the source code in a language I've never seen before and found the bug in it. EXPIRENCE to know where to look, and the simple structure of all languages allows me to do this.
Learning a programing language isn't like learning a foreign language. Once you know a LISP, a Assembly, and a C like language you can learn them all in no time. Learning a new one is like a Londoner going to the southern US. The langauge is different, but it won't take long to converse with someone there.
To answer the question: I use TCL/TK, C/C++ (C compiled with a c++ compiler, and in c++ function calling. I'm interfacing with hardware so c++ isn't of much use), and a private OOA thing (4gl?) that gets compiled to C++. They all work, and all are the same, even though the OOA doesn't support arrays to my annoyance, I can code arround that.
Oh yeah, Perl, Perl, and more Perl... it's nice ant portable, I do mostly cgi stuff, and run perl scripts on the Mac, NT (ugh!), FreeBSD, Linux... the swiss army chainsaw! the duct tape of the internet!
Mmmmm... perl....
(and occasionally UserTalk, and AppleScript)
...end of transmission...
50k line accounting package, windows though..
:)
Guess that puts me in the 20k+ group, heh...
Oh well, now I get to maintain that program, and write cool things in perl, c/c++ and java...
I like my job
Yes this is my real UID. No, it was not bought from EBay.
I wrote a whole bunch of code for classes last year. I had 5 compiler theory programs that each were around 1800 loc. Took me a while, but it all worked.
-Ben
At work, approx 50,000 lines
...
At home (personal projects) approx 15,000 lines
The 50,000 lines were Java, the 15,000 C and C++
I wish the totals were reversed, but unfortunately I have to code what other people want me to code so that I can feed myself and then code what I want to code on my time off
Sorry, K&R is the One True Style, and it uses:
...
if (...) {
...
}
That's what I use. And I *always* limit my lines to 80 columns, which may inflate my line count a little bit. Also I tend to comment fairly liberally and use whitespace abundantly when it helps to clarify code. Some of my coworkers write lines 160+ characters long (!!!) and they don't comment at all. So my 50+ Kloc is a somewhat inflated compared to them.
However, I feel that neat, readable, well organized, commented code is implicitly more valuable so while my whitespace:line ratio is higher, so is my value:line
I switched from putting the curly brace at the end of the line after fixing one too many compile problems where I thought there was a brace but there wasn't or where I thought there wasn't a brace but there was. Give me
...
if (...)
{
}
any day.
I agree with you on the 80 columns bit though, long lines mean too danged much resizing. And cygwin doesn't like to resize width-wise.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
> it just irrtates me that someone [...] gets paid $60K-$120K a year while I'm [getting] a whopping $25K per year.
Then find another job. It's not you who should be irritated by them, it's they at you for doing what you do for such a piddling wage and bringing the pay average down. It is not immoral or disloyal to leave a place where you are underpaid and overworked.
And if you're young, a certain amount of job-switching is good for you. You'll get a better sense of what work environments there are, you'll find that your best pay raises are when you change jobs, and you'll make useful contacts. Also, once you've left school, work is one of the major places to meet people, both for friends and potential mates. And it can be problematic to get involved with the latter while still working for the same company.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Heh. You mean 'LoC' should therefore be:
:)
:)
cat bigprog.cc | indent | wc -l
(or, as an added bonus, probably more like
cat obfuscated.c | grep -v ^# | cc -E - | tr -d '\n' | indent -kr | wc -l
)
I actually needed to strip carriage returns because indent couldn't figure out how to indent ascii-art-c properly... oh well...
Of course lines of code is an inaccurate, stupid, braindead, unreliable measure of productivity. So are bogomips. We still use them... However, they aren't the holy grail of software metrics or benchmarking or anything. That's why this is just a poll topic, instead of something serious.
However, if you think it *is* the holy grail, use gnu-style indenting. More lines-of-code thank k&r, so your code is suddenly better.
pb Reply or e-mail; don't vaguely moderate.
... 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".
I'm not sure, but this seems kind of like engineered information to support US companies looking for "relief" from the current IT job crunch.
Its amazing how companies dig on supply and demand until we start talking about capital/labor markets. =)
Of course, all metrics have problems, and the L.O.C. thing has been well covered, blah, blah, blah... I just don't like the idea of someone telling me that my 60 hours a week aren't good enough.
oh well...enough whining... I have to get cracking if I'm going to beat my "nonunion mexican equivilent" (to quote the simpsons).
Pax -- Ob
This sounds like the fabled Microsoft vs. IBM programming teams, where IBM employees were supposedly being paid per LOC and Microsoft employees were being paid for the job they did. The story goes that for every 10 LOC IBM wrote, Microsoft optimized it down to 1. Then they started making the IBM team look bad and things started to fall apart from there. I believe this was back in the early days of OS/2 (slightly before Microsoft excercised their license agreement and came out with their own OS/2-like system, Windows)... I guess it is the amount of code that you write that matters, not the quality, according to CNN anyway.
Too bad Microsoft can't release a program today that isn't over 100 meg compressed. That is partially why I am big into shareware and freeware, where you can often find a nicely featured, solidly written program that does what you need. For example: JASC's Paint Shop Pro. Okay, sorry you Linuxheads... The Gimp is wondiferlous too... Unfortunately, my job requires me to use Wintel machines all day...
Oh... For one decent program written outside the US, I'll name 10, no 20 programs that have been written in the US...
Large print giveth, and the small print taketh away
Then of course a lot of those are
{ return depth; }
kinds of functions, inheritance, and templates like hell. And yes, I tend to omit return values.
It just shows how far people will go to make the computer do what they want yet no corporation will ever pay anyone to code it.
For me the clear point from the article and this thread is that management of software development is still failing.
This is a key reason why free software results in higher quality software with fewer bugs.
In many companies the behaviour of management actively destroys productivity and quality. Many managers completely fail to understand software development and the people who do it.
Company Management forces software developers to spend time on none productive work. It rewards behaviour that is not aligned with quality work. It measures the wrong things.
People like DeMarco have understood this and documented it for years. Have companies listened? No.
The article in CNN clearly shows a manager who also completely fails to understand how to manage software developers. He needs training urgently.
In my last job before starting my own company I worked as a hacker and then team leader for a software company in the City of London on banking software.
That company was run and managed entirely by sales people. They did not understand AT ALL what motivates programmers/analysts and designers.
These types of managers try to measure software development by number of hours worked and LOC. The results are late, slow and buggy software.
Compare this to free software which is often developed at an amazing speed, has fantastic performance and many less bugs.
Whats the difference? Free software does not have managers!
Do the world a favour - sack a manager today!
Dave
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)
Program A
Software person 1: does it in 20k lines
Software person 2: does it in 10k lines
Which is likely the better program & programmer?
Tom
"I would have wrote it shorter, but I did not have the time" - gist of a famous quote
And then you learn more and realize the compiler figured out the loop was static and unrolled it.
. . . yeah, those benchmarks suck. The Pentium II is faster than the G3 any day. . .
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
. . . i wish more programmers documented as well as you do. Sometimes I can't read half the crap.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
well, I'm a C newbie too, and I find that one liner much easier to understand.
More verbose comments, and no unnecessary carriage returns and indention. THAT'S what your source code needs!
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
PHB?
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
hows this for a metric?
Stock Options.
If the programmers write good code, make good products, sell lots of CDs, make the company successful, they get rich.
Duh.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
No, but a guy who writes 5,000 lines that work well and are thought out IS better then the guy who just kicks out 10,000 lines of hack.. ;-P
-- I'm the root of all that's evil, but you can call me cookie..
I wonder if this is due to the development tools used. I'd like to see how many of those lines where part of Visual C++ programs, where Microsoft, in their supreme wisdom, writes half the code FOR you..
-- I'm the root of all that's evil, but you can call me cookie..
Yes, and technically, these are NOT WRITTEN lines of code..
Not to mention things like MFC.. Heck, one function call can actually serve what 500 lines would do..
-- I'm the root of all that's evil, but you can call me cookie..
Oh dear.. I USED that system in the Air Force.. ;-P YOU wrote it?? I now must kill you.. ;-P
-- I'm the root of all that's evil, but you can call me cookie..
And I'm willing to bet they actually have a life.. Terrible, isn't it..
We shall have to double their workload.. They obviously have time..
-- I'm the root of all that's evil, but you can call me cookie..
Wow. What an incredibly lame coment.
Stating on Slashdot that I like cheese since 1997.
Yes, but unfortunately, the management types that know nothing about programming buy this crap about lines of code.
If there's one thing I've learned, studies are the most effective way of lying.
Stating on Slashdot that I like cheese since 1997.
I agree with Linus Torvalds on the subject of eror checking. If it's programmed right, then there's no need for error checking. If error checking is necessary, it's time for a rewrite.
Leave the BS out and debug instead.
Stating on Slashdot that I like cheese since 1997.
Yeah--time to start putting that extraneous debugging code back in, too. Do sorts on data, then throw away the results. Add stuff like "i = i;" too, for good measure. :^)
Stating on Slashdot that I like cheese since 1997.
I'm still in the academic world (unfortunately) and have noticed that programmers from other countries (students, actually) tend to write kludgy code with lots of unnecessary code. Rewriting basic functions, that sort of thing.
Stating on Slashdot that I like cheese since 1997.
No mention of how the data were collected...for all we know, Meta Group's people could have merely mailed out a survey. There are just too many variables to do this...and I suspect this is what was done, because I seriously doubt that the researchers did line counts themselves.
Stating on Slashdot that I like cheese since 1997.
Yes, along with most the programming world. :^P
Stating on Slashdot that I like cheese since 1997.
It's a holdover from productivity measurement developed when the United States was part of the Industrial Age. The more you make, the better you are; quality be damned!
Stating on Slashdot that I like cheese since 1997.
What a ridiculous sweeping statement. So the guy who writes 1 line of code a year is better than the guy who writes 10,000?
Matt. Want XML + Apache + Stylesheets? Get AxKit.
You forgot to add:
AFTER ADVANCING ONE PAGE.
"In true sound..." -Agents of Good Root
It's nice to see a poll that really relates to my life...
20k++ aww yeah...
--
$you = new YOU;
honk() if $you->love(perl)
I am an Englishman who is working in France, for a French company and who works with French programmers daily.
I would like to say that my collegues are as competent as those of any other nationality that I have encountered. I would also like to point out that the French education system prides itself on producing very qualified (note - not competent!) "ingenieurs" - this is a word that does not completely translate into engineer as it can only be applied to university educated professionals.
At least our friend is programming in his native language (I presume) - the keywords are not translated, nor are any of the library functions. What is even worse is that if one uses "MS Dev Studio" - the help, nor the program has been internationalised!
One could therefore suggest that a Frenchman who can do what our friend does is actually MORE competent, as he is working in a foreign language!
I dunno about this poll... Some languages take fewer lines of code to do things.... O well..
Most my code was in PERL... the Programming language of the gods...
ChiefArcher
It depends a lot on what you do, but possibly even more on who you work for. A lot of orgs have "pet languages".
If you work for DOD, you'll probably use Ada. If you don't, you probably won't. Some places do everything in Smalltalk, or LISP/Scheme, or Python.
I work at a consulting company now, and we use Java, C++, Perl, and VB for pretty much everything. I personally do Java almost exclusively for work, though I know plenty of other langugages.
But I have to say that it's useful to get a broad exposure to languages, even if you rarely use some of them. At school I learned a variety of AI-oriented languages (most dialects of LISP/Scheme) and I'm much better for it, even though I never use them in RL. For one thing, it helps me "think outside the box" (to use a cliche), but it also pads the resume...more important than you expect! :-)
I'm not in the business world yet, but these numbers all seem really really low. 7,700 lines a year = 148 lines a week = 3.7 lines an hour. Huh? Who writes 3.7 lines an hour?? Who even writes at such a slow pace as even 10 lines an hour?
This makes me wonder how they define "programmer." Perhaps "programmer" is just someone who happens to write some code in his or her job.
I'm just a college freshman now, and on a good day, I'll write 500 lines (a line being defined by wc -l) in a single day. Multiply that by ~250 work days comes out to 125,000 lines in a year...
Read my lips:
PERFORM PERFORM PERFORM
DECENT DECENT DECENT
If you went to a descent school you'd be going DOWN! Maybe you're making $25K because you CAN'T FREAKING SPELL! EVER THINK OF THAT?! SPELLING FREAKING COUNTS, PEOPLE! Maybe the consultants just don't look like an IDIOT in written communications!
Arrrrrggggggghhhh!!!!
The revolution will NOT be televised.
I hear you brother! I'm currently re-implementing a program to interface with a DB in a very simple way. The totality of the files counts upwards from 14,000 lines (just a wc -l kind of count).
I estimate that when I'm finished with the project, I'll have roughtly 1 order of magnitude less than that. I.E. 1,400 lines, give or take a thousand or two.
How many lines of code did I remove?
[-- Trust the Monkey --]
Yes. I looked at only a few of my projects from the last year. A rough count gives me 20k. I regularly write more than 1500 lines of code in one day. Watch me be accused of writing bad code now. Oh well.
Your code is probably fine. Looking at your web page, it looks like a lot of the programs you've written were things you wanted to write, and that they are pretty small. What this means is that you don't have to spend as much time defining requirements (they're in your head, so you know them as well as anybody else,) meeting with clients (you're the client,) and trying to coordinate with larger teams (small project, one programmer.) These are absolutely necessary if one is to deliver large-scale software to others, but they don't produce a single line of code.
For example, the current web project that I'm on has been going on for two months, and is scheduled to go on for a third. We just finished requirements definition and design, which means no code. I'm not worried, though -- the time spent in defining the problem means that we will waste less time in coding, and probably actually write less code as a result.
Again, lines of code is not a good measure of productivity, because it doesn't distinguish between code that needed to be written, and code that didn't. It also neglects the important front-end processes that ultimately (unless taken to ridiculous extremes) compress schedules and make each line of code more efficient.
Make me aerodynamic in the evening air
at school they teach us c++, although in some of the higher classes (e.g. operating systems) c seems to be more useful.
i prefer programming in c for recreational stuff as well. i have also had jobs that required c programming. almost everything for my current job is pl/sql based (a pretty horrid crossbreed between ada and sql)
definitely you should be comfortable with c. not necessarily good, but at least competent. also learn perl. while i have never done much commercial work with it, it is an invaluable tool for quick fixes, and fast development
If I don't put anything here, will anyone recognize me anymore?
LOC is a metric that is meaningless, the only folks that use it are the idiots in management that don't understand SFA about code.
Which is better code?
main( int argc, char **argv )
{
int i, x;
for( i = 0 ; i x = ( 80 - strlen( argv[i] ) ) / 2;
printf( "%*.*s%s\n", x, x, "", argv[i] );
}
}
main(
int argc,
char **argv[]
)
{
int i;
int x;
int n;
for( ; ; ;
i = 0
i i = i + 1
)
{
x = strlen( argv[i] );
x = 80 - x;
x = x / 2;
for(
n = 0
n &nt; x
n = n + 1
)
{
printf( " " );
}
printf( "%s", argv[i] );
}
}
More lines of code does not make better code. I can crank out a more lines of code just by screwing with whitespace and the formatting as I did in the above example.
Ugh... you code in Scheme for *pleasure*? I didn't think those two words could go together...
gads that language sucks roadkill
Mostly Perl. A dab of C here and there and I once took a class in Pascal (talk about the most useless class I've ever taken .. worse than Human Sexuality).
Objective-C and Java are the language to use for object-oriented geeks like me.
How come almost nobody here seems to be using Objective-C?
LOC is no way to rate quality. The same could be said concerning all areas of our workforce. Are Amercia's ditch diggers any worse than the rest of the world because they shovel less dirt? No, we use cranes, bulldozers and such. Better tools make for less effort and better quality.
----------------
"Great spirits have always encountered violent opposition from mediocre minds." - Albert Einstein
Co-founder and designer at Music Nearby: http://musicnearby.com
I've written 50K lines of code a little less than four months, in a 2 person team. My coding speed is 500 lines a day in a coding run and I've seen people who are better than me.
Admittedly, it takes longer to debug everything, but those numbers above have to be bogus. If Rob can write 15K, slashdot, study and party, then it's not programmers that are the bottleneck, but the managers.
this poll reminds me of steve balmer talking about m$ and the time they had with ibm & os2 (revenge of the nerds, m.kringley) where the ibm suits ranting about KLOC (thousand lines of code) and how they would pay m$ per KLOC
it aint about the amount of lines of code u generate. programming is more akin to writing hiku(sp) than say telephone books, so those in the high KLOC's are either very fast programmers writing very big systems or telephone book coders featuring up their next release software...sound familiar?
peterrenshaw ~ Another Scrappy Startup
it all depends on the person writing the program or script.
How about:
Software person 3: writes a perl script to remove all the newlines
:)
Which is the bigger pain in the ass, that's the question!
Log
C, C++ (they ARE different...), Pascal, Ada, Forth, Basic (UGH- thank the Lord I'm not doing VB anymore!! :-) , TCL, Perl, Awk.
I've used all of these in my career with C, C++, Object Pascal(Delphi), and Perl being the most recently used ones...
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
You guys are nuts (but then so am I... :-)!
:->
As it is, I claimed I did 15k-19,999; it seemed like boasting to claim the 20+ Kloc slot (Even if it is very true!), and I try not to boast...
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Depends upon how many apps/libs/etc. you're doing that coding to. I had to work with over 20 differing components for document imaging, some of which I started from ground zero, some were written by others and I had to pay for THIER sins (i.e. I had to rip it apart and put it back together, literally making a new component)- and had to worry about 16 versus 32 bit code, 95 versus NT (Because they ARE different in MANY ways), doing things with APIs that are plain flat broken (use wise- they SCREAM at doing what they do...), having to roll your own imaging functions because some of your libraries don't do enough to make the component work the way that the exec wants to)
It actually depends on what you're doing- you could be doing very quality stuff (I did as few lines/operations as possible...) but you could be doing a lot of it.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
What if Programmer A's code is more stable, does error checking, etc.? I'd say that it was A that did a better job than B. Which, of course, helps prove the point you were reaching at- your premise is a bit off, that's all...
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
>>IT professionals have become "fat and happy"
what a terrible thing! somebody has become happy. We need to stamp this out immediatly
This has been around for many years. Seemed like an appropriate response. http://www.sunshines.com/Humor/programmers_evoluti on.htm
Those numbers are just way too low. I pinpointed all of the source code I wrote in 1998 in all of the public directories all of us programmers use to store code. I then cat'd all my source in the first directory and piped it through 'wc' which resulted in just over 60,000 LINES. The next one at 45,000, and the next one at 25,000.
That's 130,000 LOC in 1998 for me. And that's not even unreasonable. Look at it this way:
130,000 LOC / 2,080 hours/yr = 62.5 LOC per hour, or 500 LOC/day. And this includes reading slashdot 5 times a day, other news sites, ComputerWorld magazine (which I saw this article in), dealing with bitchy customers who don't know what they want. And I thought I was SLACKING because I read slashdot, etc. 5 times a day. Damn. I sure as heck deserve a raise.
i write text. ;)
couldn't write a line of code to save my life, aside from some basic Perl. but i think i've even forgotten how to do that.
but, that's why i don't program. my calling's different.
-- haaz.
I'm not a programmer, but I've always worked under the assumption that if you can program the same features/functions in fewer LOC, it's a more elegant and efficient program.
The variables were not short. Since I didn't recognize most of them as English, I can only assume they were not. The ones that I recognized as English didn't flow the way a native English speaker would have written them, such as NumberPO instead of PONumber. Reversed "word order" is minor compared to non-english variables, but it still throws you off when analyzing the programs.
I've not worked there for quite some time so I don't have actual examples handy.
Why would you find it hard to swallow that the variables were not in English? I've looked at many non-work related source code files from non-English speakers and regularly see variables names that don't mean anything to me without a translation dictionary(babelfish proves useful for this).
you have probably seen more code generated by Indian programmers than I have
Not necessarily. I originally supported EDI for one of the "children" companies of the corporation I worked for. There we used different software than the parent company did. Last summer I took a promotion to manage the newly consolidated EDI group which was to support the entire corporation. This is when I moved to the corporate building and experienced a few of the programs written by the Indian company. Since the programs I dealt with were for the EDI module, it's entirely likely they were written by the same person(or group).
I found I didn't care for the managerial position(dealt more with managing other manager's ego trips than anything). I left in November when I was offered a programming position at a start-up company that my best friend works for.
I used this experience as an example to show that outsourcing to a low-cost solution might not be all it's cracked up to be. Sure the up-front savings are great but the maintainence issues could easily overrun those savings once the product is in actual use.
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.
Couldnt be more true.
Traxus.
Disbelieve this story at your own risk.
One day a co-worker of mine came to me with an emergency. There were only two days left before the code freeze on the product that he was
working on, and he hadn't yet gotten one large part of his project done.
Basically, his product consisted of a UI and a database, and when the customer bought the program the database would already be filled with
lots of useful entries. My co-worker had the UI part of his program done, and all of the hooks into the database were complete, but the
database was empty.
There were two ways in which he could populate the database. One was to use his program to add entries one at a time, and the other was to
populate the database via a C++ API. The former method was totally out of the question, since this would have taken *decades* to accomplish. The latter method was complicated by the fact that the
C++ API was somewhat convoluted, and even if this method was used a *lot* of code would need to be written. And my co-worker had less than two days to get this database populated.
So my co-worker came to me and asked for help. He explained to me that this was an emergency, so I started hacking....
I hacked, and I hacked, and I hacked...
In around 6 hours I cobbled together a compiler (written in Perl) that converted the raw data that we had into the C++ code that would populate the database. I ran this compiler on the data and ended up with around 100 files consisting of ~375,000 lines of code.
(interesting point: some of the functions in my generated code were ~8000 lines long -- all of the Unix C++ compilers that I had to compile this code with handled this code just fine, but Microsoft's
VC++ blew up spectacularly and I had to spend almost another 4 hours restructuring the code so that the braindead VC++ compiler could
handle the code)
Do I deserve credit for the 375,000 lines of code? Well, that's debatable. Certainly there's going to be somebody out there who will claim that I only deserve credit for the code that comprised the compiler. However, I do have to point out that I started out in the morning with not-very-much at all (just some rudimentary tools that I had written) and by the end of the day I had 375000 lines of code. Sure, I cheated, but whoever said that cheating was wrong in this
situation?
I'm, err, a very *creative* person and I do this sort of thing kindof often...
I never could have done any of this without the tools that I was using that day: a Unix box, Emacs, and most especially Perl, whose
regular-expression features I beat to death that day.
Just another Perl and compiler hacker,
--kevin (kclark@cabletron.com)
but I spend a lot of time counting the ones I already wrote. Then I spend even more time fillling out surveys about how many lines of code I write. Perhaps if there were fewer surveys, I might get something done :)
If ten thousand monkeys, with ten thousand editors, wrote 80 million lines of code, one of them would write the works of Shakespeare ( or maybe of Linux Torvalds?)..
Maurice W. Hilarius Voice: (778) 347-9907
Fewer lines of code means fewer bugs, and usually makes the program easier to understand (since there is less code to read). There is a point where brevity turns into obfuscation, but that is usually on the micro-scale, and usually doesn't apply to whole programs.
it depends, when there's a bug in a line, i rewrote it... anyway the number of line of code per engineer per day is less than 10
--
"Science will win because it works." - Stephen Hawking
why write code when program can write it for yourself? i'm using the ApBuilder from QNX/Photon for those who know it, i click 2 or 3 times, write a label, click generate, click make and it works! then i can do a wc -l *.h *.c and wow what's a number! :o)
--
"Science will win because it works." - Stephen Hawking
the only one i used for X was Architect in the early 90's, using QNX/Photon is far far away from X/Motif, it's really simplier, and the ApBuilder does what exactly what you'd like to code
--
"Science will win because it works." - Stephen Hawking
You never ovbiously used NeXT's.
no... is there a i386 version? i'm using also BeOS and i heard its GUI feels like NeXT, but there's no ApBuilder (yet) under BeOS...
--
"Science will win because it works." - Stephen Hawking
Imagine the productivity measurement if you excluded the NT5 development team. Man, our numbers would drop even more!
Productivity != efficiency. I don't know why studies are still done based upon lines of code.
Well, I suppose we all just need to start writing
everything in cobol, that should make us way more
productive than everyone else. Right?
Casca
I'm split about 90/10 in C++/Java, with a sprinkling of (ready?) Lingo. Yep, Macromedia Director: Oh, the pain.
--Mark
Not neccessarily. If you make your code so convoluted its unreadable, that definately doesn't make your program better, it just makes life harder for the poor sod that has to maintain it (even if its you).
If I remove all the whitespace from a 30K source file, does that make it a single LOC?
Line count isn't the best metric around, but it is *A* metric, which is more than some people have going for them.
Metrics while generally a good thing are like benchmarks. They have little meaning in and of themselves, and are prone to misinterpretation by pointy-haired idiots.
--Mark
Its not so bad. The lab credit is pretty much a toss-up though. It really depends on your partner... ;)
--Mark
Never heard the story, but it's surprising that Yourdon is quoted in the CNN story on the opposite side of the issue, saying that LOC == productivity. Maybe he should fess up and admit that all the American programmers are busy building bomb shelters and polishing their AK47's for Y2K.
Big Ed should look at some real measure of productivity, like $ revenue / programmer.
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
PERL, much like the so named TCL, is basically a tool command language. The different may be that most of the tools have become part of PERL itself.
Can you really compare a PERL program that can outsource many operations to functions not availiable in C to a C program that had to do many operations itself?
I don't argue against the slowness so much as the difference in length of code and length of run.
19000 c/c++ code for my Master's thesis.
+another 3600 lines of latex code for the document itself. Does anyone know if latex is Turing complete?
So long, and thanks for all the Phish
- Visual Basic (Great for bloating LOC: You can acheive COBOL-like verbosity if you put your mind to it.)
- C++
- PL/SQL
Home:- VB
- Java
- Python (newbie)
Computer languages are much like any other language. Volume and effectiveness/efficiency have almost no relation. William Gibson can pack more story into one chapter than Harold Robbins can into an entire book. If novels were held to the same standard as source code, Gibson would be a script kiddie, and Robbins a wizard.This "study" is a classic. Somebody wanted to show that American programmers are "lazy", so they picked the old Lines of Code metric, which they knew would validate their assertion, without any other metrics to undermine that assertion. Redirect this to
Keith Russell
Whatever happened to peaceful coexistance?
This sig intentionally left blank.
I've noticed that to be true here. As I said in the article on whether or not geeks should attend college, I find the inclusion of COBOL in the curriculum here to be pretty dumb. I realize it's still in wide use in a bunch of older systems, but I dunno, methinks I'd rather learn something that'll have more future applications. As far as actual use, I do most coding in C++, whether for class or for personal use.
-mike kania
Um, this is a slashdot poll, as far as I know.
Myself, I puyt 20k+LOC, because that's what wc -l said for my projects from last year (if you count personal time, work and class), though I guess since only about 5k of those were for work, I could be considered a slacker, right? (The rest being either required for class or completely recreational.) My coding style is a sane one, i.e. (the _s are just because of the lack of proper code formatting here):
int main(int argc, char *argv[])
{
_ _ for (int i = 0; i argc; i++)
_ _ _ _ printf ("Argument %d = '%s'\n", i, argv[i]);
}
Of course, comparing "hello world" programs for LOC is pretty much pointless. Even with a lot of documentation, any sufficiently-complex project will have a much greater magnitude of actual code lines than of comments or whitespace (style depending, of course, but if you have more than one blank line at a time you need some serious help anyway).
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
It took me a while to think of this, but why not use McCabe complexity to gauge the complexity of a project? (The McCabe complexity is, simply speaking, the number of branches in a program.) LOC and documentation and coding style then become a non-issue.
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
At my work, we are migrating project from being OWL-based with Borland C++ 4.52 that contains approximately 50,000 lines of code to C++ Builder. I have already duplicated most of the user interface functionality of the previous version, in some cases not writing a line of code -- using the VCL -- and in other cases writing 1/4 of the lines of code. The new version is much easier to understand and to modify -- just because the older is > 4x the new certainly doesn't make it more productive!
Yeah, when I tried the college thing a couple of years ago they tried teaching me COBOL. It's really a joke. I know, I know.. they're trying to teach some kind of fundamentals or something.
I work for an ISP and find that I write most of my stuff in Perl. There's a huge module base (I love CPAN!) and that makes it easy to do complex things.
You got a girlfriend? The Frenchman does... ;-)
-------
Warning: Slashdot may contain traces of nuts.
So we code more efficiently.
Don't blame us for that.
In a commercial developement house, programmers do many other things than just program. Those things take time here is a short list of my immediate tasks.
1. Gathering Requirments for the next release
2. Writing the Spec for the next release
3. Designing the the next release
4. Coding
5. Unit Test
6. Integration Testing
7. Status Reports
8. Programmer Doc's
9. User Doc's
10. Meetings to discuss all of the above
All of these things take time, so to claim that someone is not as productive as someone else, you must compare apples to apples. What are the procedures that are being used for developement? How extensive is the QA process?
You want medical software to be very well tested, while a web browser can fail and noone dies.
So, I think productivities is a complex issue and LOC does not do it justice.
Troy
To me, if I have to write code it means that the tool isn't there to solve my problem already. So I'm better off when I don't write any, by my standard.
Now if you asked my how much code I've _read_, that would be a different story indeed. Even if I just use it, I still like to see how it works.
Of course, the other reason I don't like to write code is because I suck at it.
-- Josh Turiel
"2. Do not eat iPod Shuffle."
Brian?!? I think you should leave him out of this. He hasn't harmed anyone.
Surely the solution is simple: write everything in INTERCAL.
I guess you'd consider me a fellow cpsc student, as i program mostly in c++... i guess i should learn something more useful like perl, and i taught myself html as well (which really isn't programming, just a fun thing to learn)...
- webfreak
To write a program that counts to 100 you can do it in 100 lines of code:
print 1
print 2
print 3
etc.
or you can do it in 3 lines:
for (i=1;i=i++;i=100)
print i
next i
or something..... Now who is the better programmer?
$ wc `find . -name '*.pl'` | tail -1
.pl, and only stuff that I wrote for one job last year. I guess if I include all the stuff I wrote for classes, for fun, etc... it puts me in the 20k range. Yipes!
9874 33521 274122 total
That's just Perl, only in stuff with
Of course, this led to hundreds of one-line (litteraly) routines which simply stored a value or incremented a counter -- each having the required standardized header. These programmers generated MILLIONS of lines of code.
I say, "Bravo."
Needless to say, those millions of lines of code were unbelieveably bug ridden. In my project, I took 20K lines of this stuff, doubled the functionality, doubled the throughput, eliminated the known bug list, ported the system to two other machines, and ended up with 12K lines.
I must be part of the problem...
I code C++, PHP3, SQL, and a smidget of C here and there. PHP3, and SQL I use for web developement and C++ is my fav for application work. The language you use really depends upon the line of work you're in.
Quandary in the Making
It really depends on the purpose.
Work: Ada almost exclusively. Some Perl scripting.
Home: C, C++, Java, Perl. Dabbling a bit in Objective-C.
Russell Ahrens
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
laziness, impatience, and hubris
Paul
paul@ebb.org
And English isn't his native tongue. sigh Some people just don't understand the value of consistent, concise, mnemonic variable names.
--Joe
--
Program Intellivision!
$1 for the chalk, $49,999 for knowing where to mark.
--
Program Intellivision!
I hope my c.s. prof's aren't reading this :)
-Ragnarok
Search first, ask questions later.
Scheme is cool. Simple, fun. The problem you get is sooo many people grew up in Algol-like languages (C, C++, Pascal, Java, etc...). You get to a Scheme or LISP, and it's sooo alien. My first college programming was taught in Scheme. I loved it. I'm just now (3 years later) beggining to _like_ C++.
You can code stuff up so fast in Scheme (or Lisp). Some things that take 50 "lines" in C++ can take as few as 5 or 10 in Scheme. The confusing thing is how everything is a function and recursive. If you need to do something iteratively, you need to write a driver and a helper function which reduces clarity.
Hope the torches aren't lighting now, but my point is: don't knock Scheme... It's a really useful, easy to use little language that anyone can be productive in after very few hours of training.
STUPID engineers produce 10 lines of code a day.
Brilliant ones can do orders of magnitude more
than that. I've heard this idiotic statistic
for years -- I've never believed it, largely
because it does not in any way match experience
with smart and educated programmers.
Perl - for one-liners, filters and sundry one-shot stuff
C - My language of choice. For most 'real' stuff.
C++ - When I have to (like when my stuff is to be used with existing C++ code).
SmallC - Use it to program the HC11 (together with assembler).
Generally, I find that languages that are themselves low on features (read: bells and whistles), but are easily extended through libraries are the easiest, most efficient to work with. With C++, you tend to spend a disproportionate amount of time second-guessing the compiler instead of working on your problem -- this of course depends on how much of the C++ features you actually use.
Trust the Computer. The Computer is your friend.
logan
and some Java for school (yech)
Having worked with (and spoken too) a lot of Indian programmers, I agree with you. Many of the Indians who work as programmers have better English than many Englishmen. I find Indian Enlgish easier to understand than some of the Scots English and East-Anglian English I listen to every day.
It's ONE.
The function declaration and the return are
not procedure steps... Okay maybe the
return is. So it's two maybe.
-fb Everything not expressly forbidden is now mandatory.
Thanks to all the open source out there (especially the libraries) I was able to complete a project last year without unneccessary work. (appox. 600 LOC vs the 5000+ LOC of the previous version.)
It's a well-known proverb that the best hackers are the lazy ones: code reuse.
P.S. Remember Steve Balmer complaining in "Triumph of the Nerds" about IBM's obsession with "kaylocs" in the OS/2 project? Well I guess M$ learnt that lesson well, Steve. What about all those MEGAlocs in Windows xx?
In my company we have this daft 'coding standard' forced upon us that means, that apart from illogical hungarian notation, we have to do stupid things like:
/* Set iBletch according to the foo coefficient of iBar */
if( 0 != iFoo(iBar) )
{
iBletch = 1;
}
else
{
iBletch = 2;
}
instead of (among other possibilities)
bletch = foo(bar)?1:2;
Comes of having too many managers reading code that they have virtually no business reading, without having any idea of what it is the code is supposed to do overall, let alone any single part of it.
Consequently, I bet even our student programmers churn out 20,000+ lines of code a year. All those redundant braces give me vertigo.
20k loc is too low! I've done that in six months!
--Rob
Fortran baby!
(And C when I am not changing already existing code...)
I find it rather interesting that, after 474 comments, no one has noticed that the poll doesn't say, "More lines is better." Nor does it say "Fewer lines is better."
All the poll asks is how many lines of code you wrote last year.
I've found that the number of lines I write can really depend on what I'm doing. Writing perl data munging scripts and web bots can take only a few lines. When you write code that does interface stuff the lines shoot up. It's a really rough estimate. I said 15 to 20, but thinking about it's probally more. Who actually keeps track of this kind of stuff?
The power of technology is manifest in how it is applied within the social matrix.
Obviously, they've taken these things into account, right?
hmmm... look at the math/statistics of it. you write say . . . 5 LOC, compsci-boi does 20 LOC, if you have a bug, its so much easier to find it, less places to look, less places for it to get screwed up.
While the article does report that there is a decrease in lines of code, I find it distressing to find that the biggest complaint is that American programmers are no longer working 70-hour weeks and the executives plan to "light a fire" to get them to overwork themselves. This is yet another distressing look at how business looks more at the bottom line rather trying to figure out how to work efficently. Executives mumble "work smarter, not harder," but then they start looking at these silly statistics to judge programmers. What a crock.
Another telling remark from the article is European "productivity" is due to the fact that they used "packaged software" more than in the States. So all of that Visual software may be forcing those poor Europeans to write more lines of code than they should. I apologize to our fellow programmers in Europe. If we could stop MS from making crap, we would.
A few posters have already mentioned the fact that they spend most of their time writing specifications (good), design and development plans (good), and dealing with the bureaucracy of micromanagement (very bad). The slowdown in code production might also be due to American business' obsession inability to let the reins free and let coders be coders. It's not 9-5 that counts, it's the midnight-three burst of inspired, brilliant code that counts. It's the knowledge that design definitions aren't moving targets that calms the programmer. It's realistic deadlines that allows the coder to plan. It's not having to look over the shoulder every minute that lets the programmer think of solid code instead of changing jobs.
Or is that just me?
-S. Louie
"I may be Love's bitch, but at least I'm man enough to admit it."
I don't get these numbers. 20,000 lines, in 50 weeks, is just 400 LOC/wk. Just 400 lines? Ha! No problem where I work. Granted, we're not writing C, but heck... I know I do at *least* 400 LOC per week. And there are three of us.
DFL
Never send a human to do a machine's job.
Elsewise:
DFL
Never send a human to do a machine's job.
Perhaps Non-American coders just don't optimize as much? I mean, I guess you could say I've "written" 100,000 lines of code this year so far, but I've also copied, pasted, reused and modularized up the wazoo. The skill in programming isn't generating mass amounts of code, it is about generating the most functionality with the fewest lines of code possible, isn't it?
It will make even more sense (if any exists at all): the bigger your code the more functions supposedly it will do.
Delphi/VB5/other lame languages are exempt for obvious reason unless you used dynamicly linked library (not to bload your exe). Your DLLs are ok.
AtW,
http://www.investigatio.com
alexc
Join Majestic-12 Distributed Search Engine
I typed at least 20,000 LOC, but I most didn't make it to production. ~60,0000 LOC that were generated by my code did make it to production though, so it is hard to measure.
LOC suck anyway. I could write a 300 line HelloWorld.java. Would that make me a better programer?
My most productive days have resulted in net negative LOC!
Joe
Joe Batt Solid Design
This:
SUBTRACT ONE FROM WS-NUMBER-OF-CREDITS-REMAINING.
MOVE WS-NUMBER-OF-CREDITS-REMAINING
TO WS-DISPLAY-CREDITS-REMAINING.
PERFORM 4000-DISPLAY-CREDITS-REMAINING
THRU 4000-DISPLAY-CREDITS-REMAINING-EXIT.
could probably be done in a lot less lines in another language. Perhaps even one line, making for an 80% reduction in the number of lines of code.
Then, of course, there is the whole issue of efficiency -- writing more lines of code does not mean better code, or even more functionality.
Stupid people will be persecuted to the fullest extent allowed by law.
COBOL (80%)
Powerhouse (12%)
Visual Basic (3%)
JCL/Scripts/Macros/Etc. (5%)
Home/Fun/Personal Web:
QBasic (MS-DOS) (45%)
Perl (45%)
Visual Basic (10%)
And before you laugh at me for being a COBOL programmer, keep in mind that I made a ton of money last year, working from home in the buff. So there. 8^)
Stupid people will be persecuted to the fullest extent allowed by law.
See also http:/ /www.cis.ohio-state.edu/hypertext/faq/usenet/compi lers/free/part2/faq.html for a PL/M compiler, and http://home.sol.no/~egilk/download.html for a PL/M to C converter.
While you're at it, [Plug] check out my classic computers site and the Vintage Computer Festival.[/Plug]
Stupid people will be persecuted to the fullest extent allowed by law.
#1 meant MS-DOS, eliminating VB, Java, etc. #2 and #3 eliminated C, Perl, etc. QBasic was available, I knew it, you can do reasonably structured programming, and so on. It fit.
Since then, one of those projects has since been ported to Perl as a CGI script, but the code remains much the same.
Anyway, I'm not ashamed of my choice; It's a quick and easy language to work with, and fits the bill. There are no bad languages, only bad programmers. 8^)
Stupid people will be persecuted to the fullest extent allowed by law.
One compiler engineering class: >6000 lines
Fun code for myself: 100 lines.
Last year, I led a project to port an AP101 emulator (virtual machine) from RS/6000 assembly language on AIX to portable C++. We didn't generate a huge new codebase, but we were very productive. Some very productive days, I didn't write a single line of code -- I disassembled and documented RS6K assembly trying to understand how the emulator worked (the original programmer was long since gone and didn't comment his code).
Lots of programming jobs in this country involve porting. Lots of others, especially as we approach Y2K, are involved in maintenance of existing codebases. Many other tasks consist of tweaking and tuning existing code. Still others are integration projects -- taking existing bodies of code and making them work together.
Given that the US has been using computers as long or longer than any other country, it's possible (probable?) that we have a higher percentage of our programmers in these maintenance-type jobs. I'd bet that if you compare productivity of programmers whose jobs are exclusively to generate new code, the US would stack up better.
--JT
The only portable Id put a PIII in would be a sodding toaster, I mean, you could cook your breakfast on it on the train to work in the mornings... =)
- --------------------+
...thats not a bad idea really.....I could have an extra 3 mins in bed in the morning......
+----------------------------------------------
+---+
"The fish of life eats the brain out of my foot" the wise man said...
I think most readers here would ALSO agree that articles such as this are a dangerous thing when they wind up in the hands of managers. The quote that bothers me the most:
"Garrin said he plans to step up the measurement of IT costs and staff productivity "to light a fire under people and show them where they stand."
While I would love to be paid by number of bugs fixed, or number of lines written, it would quickly bring about ruin for my company.
What IS interesting is the question of why there exists a discrepancy between LOC/programmer in the study. We know that this is not necessarily a reflection of quality, and if it is, whose programmers come out ahead.
I would like to know how the "16,000 information technology professionals in 28 nations" were chosen. Given that Howard Rubin issues no disclaimers about using LOC as a benchmark, I wouldn't be surprised to find that the foreign companies were of a different character than the U.S. counterparts, perhaps ones that have more international visibility. These Connecticut-based researchers should have an easier time finding small firms to poll locally. Maybe the U.S. companies participated in different kinds of software development than the others, for instance a larger proportion of products like games (my territory) that do not often have the luxury of code reuse. What we are probably seeing is an antecedent variable, something that IMHO is the single biggest reason why statistics are most often just lies.
Judge software by how useful it is to you; by that measure the U.S. produces many programs that are good and many that are not.
I say 6 based upon K&R formatting. whitespace should never count but functions are special and deserve the extra two. things like
if(x)
{
should be formatted as
if(x) {
so only one line is present. The reason functions have formats is that they are special. After all you can't nest functions in C so they should look a little different. I like it this way because all that you have to do is remove whitespace (if you are using K&R formatting of course, the one true formatting style) to get your lines.
Suddenly, the hairy finger of a familiar monkey tapped me on the shoulder. It was time.--G. T.
brian?
Huh?
Who's brian?
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.
High-level languages have been invented guys!
But if you can write that much assembler in a year, all power to ya, you code-gods!
So far it looks like an even spread. 2 for "less than 1000" and 2 for "1000-1500".
I think most people here would be in the "less than 1000", including me. Of course, if you count all the lines of code that 1 line of python code leverages.. I guess you could argue that I wrote more than 1000.
And I'm sure some guy out there will just run vi (or emacs for the sorry vi-challenged people), type one ' printf("wheee") ', and then yank and paste 'till the sun comes up, and legitimately call it his 1000 (or 1000000) line program...
lotsa loopholes.
-Laxative
I think aseembly programmers who write lines of codes that consist merely of things like:
mov ax, bx
etc...
would have the distinct advantage of looking cooler in this pole because what would take a C programmer one line could take an assembly programmer 10, 20, even 30 lines
and some programmers are sloppier than others
is one working harder if he writes 100 lines of code when somebody else can do the job in 50?
there's got to be a better way of judging efficiency
having said that: I have no idea what this could be
--- Ralph the Wonder Llama lives!
I have NO idea how many lines of code I've written in the past year. None. This year I have written 6 complete dynamic-content web sites in Python and Perl. I have written about a dozen freeware and shareware programs. I've done about 6 dozen CGI scripts for various purposes. I've done a lot of RealBasic programming on my Mac just for the fun of it. How efficient am I? I don't know. All of my code works, and it all does what I intended for it to do. Isn't that what matters. Don't blame CNN, because they just report what other people give them. Blame the idiots that released the study.
- Vincit qui patitur.
Why hasn't anyone mentioned this before? This would have been the best place to mention Open Source. Alas, the author may not know about it since he mostly writes about Y2K problems for CNN.
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
Richard von Weizs
Depending on the size of the statement my style changes.
for instance:
if the functions are VERY large I will perform:
(!sex) ? sex() : already_doingit();
else if its a medium function it will be :
if(!sex) {
printf ("im having sex");
// perverse comment here
for(bob) {
bob();
}
}
else if its extremely short ill do:
(!sex) ? printf("hey baby, lets have sex") : printf("a 3-some ?? eww");
C, Perl, C++ (a wee bit) and (alas) FORTRAN. However, if you can avoid FORTRAN, do so at all costs. I only used it because I had to modify a huge code which was already in FORTRAN.
--Artemisia
I'm not a software engineer, and certainly not a management type. I normally collect statistics such as these--from one of the project I did last year. I've removed the directory names so that my boss won't recognize the project. ;-)
dir1 dir2 dir3
semicolons: 6277 2219 682
fors: 275 84 25 = 384
ifs: 881 409 79
switches: 21 28 5
cases: 75 83 18
totals: 7529 2823 809 = 11161
#functions: 72 90 16
Sorry for how unreadable the table is.
Clearly, these statistics aren't linearly independent. The number of lines containing semicolons includes the lines containing for statements. But still this gives you a sense of how complicated your code is, not just how many lines it is. The ultimate goal is to be able to say something other than "as long as it takes" when asked how long something will take.
Combining this with my other projects, I would guess that I wrote about 14-15K lines of code last year, another 14-15K lines of comments and a 90 page users manual. Pretty puny really.
Now Americans have a monopoly on honesty ?
:)
Didn't you know that? They bought up the patent last week...
Based on my exposure to Americans I can conclude they are arrogant f_cks, convinced of their own superiority.
Neah, they're not all like that... unfortunately, the ones that are like that also tend to be the loudest of the bunch...
'Scuse me, I've gotta dig my way out of the Igloo now to feed the sled dogs. (I'm Canadian, we all do that. Really.
you code in Scheme for *pleasure*?
Sure! It's great for us bracket obsessed people (Who don't want to program in lisp, that is. (Of course, we could do both.)) Also, as a 'functional' (as in mathematical functions, not as in 'I can write functions in C' functions, those are procedural languages.) language it's fun to figure out how to do stuff that would otherwise be 'step 1, step 2, step 3,...' all in one recursive burst.
Heck, in one of my programming theory classes, we had to write a scheme interpreter. Of course, the prof didn't bother telling us that, he just handed us the language spec in BNF, and said 'Write the interpreter, all in C or C++, and you're not allowed to use lex or yacc. Hand it in on Monday.' Ack, I hated writing interpreters over the weekend. Then again, I wasn't too fond of writing interpreters any time... Oh well.
Brilliant engineers don't need to produce orders of magnitude more code than 10 lines a day.
Two stories:
A person is sitting near me at my current company. He's not the brightest person I've met, but man does he code. He's written more lines of code than most of the rest of us put together. Most of it is crap.
My boss once made a fix to a driver for some random hardware the company he worked at was building. It was a 2 byte fix, but it took a week to find and make. It's one of the pieces of code he's most proud of.
A good programmer should be able to write excellent code. A great programmer is someone who knows when they don't have to.
Later,
Blake.
I speak for PCDocs
At the workplace:
Visual C++, Visual Basic, VBScript, JScript, Java. HTML too, but I don't consider that coding.
Recreationally:
Python, C++ (Mmmm... STL...), C, a smattering of Perl.
Say, that would be an interesting poll question. Is there any way we can select more than one option in the poll?
Later,
Blake.
I speak for PCDocs
Sure, just by replacing INPUT type=radio with INPUT type=checkbox
Yeah, but is the backend set up to handle choices of that type or would we suddenly get totals way above 100, and break the poll?
Later,
Blake.
(I really gotta put that into my sig...)
I speak for PCDocs
Here I thought that I was extremely productive when I scrapped a 1,000+ line program written by a predecessor and rewrote it in under 100 lines. I guess programmers who reuse code are less productive than then brute-force coders.
-- Don't Tase me, bro!
But then I guess I'm being hypocritical... oh well.
Davo -- Free speech, free software, AND free beer.
my first name is one of the choices, but my pick was obvious...
ROFLMAO
One of my primary goals when writing something is to use as little source code as possible. Otherwise you risk creating bloatware which is a Microsoft crime.
Write it this way:
#include
int main(
int argc,
char **argv
)
{
printf(
"H"
"e"
"l"
"l"
"o"
","
" "
"w"
"o"
"r"
"l"
"d"
"."
"\n"
);
return 0;
}
I think you would be almost three times as productive this way.
-Paul
(This message was not intended for the sarcasm impaired.)
Edu. sig-line: Choose rhymes with lose. Chose rhymes with goes. Loose rhymes with goose.
Comparing? THEN use THAN.
Cool, what does said 1172 lines do? BTW, nice nickname you've got. :)
We americans just write more eficient code
"However," replied the universe, "The fact has not created in me A sense of obligation."
I am lazy. It affects my career movement if left unchecked. I admit this :).
:).
BUT, on another note, I spend the majority of my time cranking out design documentation and reviewing other people's work vs. coding. This way, we put out code that is pretty rock solid.
On my last project, I worked with a European group on different facets of an entire system, fairly equal amounts of development time. When we were just finishing up design reviews and starting coding, they mentioned that they were requesting our code to begin testing. We came close to missing our deadline, but got it out on time. I had perhaps one major issue that was my bad, and I fixed it in about two days after shipping it.
I then spent the next TWO MONTHS getting bug reports from them that they had this or that error in the system, and could I please take a look at it. EVERY time, the bug turned out to be in their code. They cranked out their code faster, but it was completely bug-ridden, and worse yet, they were nearly incapable of debugging the system effectively because they didn't spend enough time understanding the design. At the end of it all, we started examining their code for them (which was very painful, because it was not written well at all), which is a total violation of the black-box paradigm and quite frankly not my job.
BTW, the extra delay between when they asked for our code and when we sent it to them was a matter of two weeks or so, not the two months it took to get their code workable.
Of course, all the time I spent fixing their bugs could have been spent cranking out more code
This is certainly not meant to shed a bad light on European developers in general, just a description of the ideas of spending time designing and reviewing your code vs. crank-it-out and fix the bugs on a half-ass implementation. Friends of mine have had quite a few similar experiences with American groups.
I do suspect though, that American firms are trying to design a little more than our overseas friends.
The most hilarious part of it all, though, was that the other group we were working with was supposedly an SEI level 5 shop, meaning that they have a full-featured design process, whereas we are only SEI 3. I suppose it all depends on how you present the info to the auditors.
I must have enjoyed pain when I was younger...
But it does provide a nice foundation for programming and computer know-how.
fink
Exactly. And I never gave permission for my name to be used in a /. poll anyway :-)
--Brian
probably 'strucuture and interpretation of
computer programs' by abelson and sussman...
we used it at WPI too..
tremendously good book about getting started in
programming.. it teaches a little scheme along the
way, but definitely isn't about that.
I hear WPI starts with something more traditional
like C these days.. that used to be only true for
non majors.. too bad really.
Mostly Java at this point. Some C/C++, and looking into Delphi. As recently as two months ago, I worked with FORTRAN every day, and swatted at VB(A). Also looking for an excuse to pick up Perl and maybe Python skills on the side.
Actually, here's a kick - speaking of lines of code written: Just the other day I needed to write a really ugly if-elseif in Java... Went on for, oh hundreds of lines... I whipped up a ksh script to write it for me. Took 7 lines. Which counts? The script or the generated code??
And, while on the subject of LOC: If I use VC++6.0, and run wizards, do I get to count those gen'd lines toward my raise??
-- What you do today will cost you a day of your life.
It takes them significantly less time to build a building or dig a tunnel than it used to a hundred years ago. They cheat by using dynamite, jackhammers and other power tools, instead of good old fashioned elbow grease.
By that same metric, programmers are lazy as dirt.
If I can write, in a single line of code, the instruction to generate a dialog box, then I am lazy.
If I were to insist on writing the assembly instructions resulting in the same dialog box - well, I'd be stupid. It's about simplifying our job with tools.
It's truly a pity that the media is ignorant of the issues on which they report.
What the article should say is that American programmers have the best tools available. Tools that are at least twice as good as of their European counterparts. Since, with less resulting code, we manage to generate more software. I know, there'a bloatware argument here rearing it's ugly head..
But, given the right tool for the job, the reams of code needed are easily reduced to a handful of instructions. Take Java for UI implementation, Perl for text processing, C/C++ for the grunge, and you've got a great toolset.
Also, good programmers write lots of code, great programmers steal lots of code. Not only is laziness a virtue; code reuse, de-redundification of source code, modularity and OO are all sound software design.
It's just too bad that the general public, whose opinion is formed by the ignorant media, is equally ignorant of the facts.
-- What you do today will cost you a day of your life.
What IS interesting is the question of why there exists a discrepancy between LOC/programmer in the study
Here's my guess: The people US programmers were compared against are not as sophisticated. Rather then knowing their API and using available libraries, they reinvent the wheel each and every time. They remember their academic exercises as gospel, and reimplement atoi() each time there's a need for it. They know basic control and data structures, but are not willing to roll their own, thereby requiring more code to accomplish the same task. They cut and paste rather than modularize and hide in a call.
See the taxonomy of programmer competence, and send a copy to the author of the CNN article.
-- What you do today will cost you a day of your life.
No one really thinks function codes are a good measure of software. There was a decent article
in scientific american about using function points to measure code
The Math Maestro Tutoring Services in Seattle
REXX, C, Bourne shell (eek), PL/I (don't laugh--Visual Age PL/I is fun!), COBOL (although not lately and not very well), BASIC/Basic, Intel IA-16, Intel IA-32, elisp (mostly Scheme), Java, and a couple other languages that I forget right now. Oh yes, SOM, that's it.
--jon. Postel is dead. May we all mourn his, and our, loss.
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
Its not about LOC, its about innovation. I've worked with Euro's, taken over projects from Israeli's and Russians and I have got to say, there is a major cultural difference that displays itself even in the code.
.0001% occurrance.
The code tends to be a bit over-engineered and top heavy. Where an american programmer might say 'Ok, this gets the job done and is fairly bullet proof, lets go with it' an overseas programmer will go through some friggin amazing hoops to take care of the
At this time also, overseas programmers are just not as innovative for the most part. They are great at 'doing a project' but they are not good at 'coming up with the project from conception to completion' like US programmers are. A US programmer is hired to design, develop, maintain and evolve a system. An overseas programmer is generally hired to write the code.
This is all generalizations from my experience and most likely subject to change, but it has been my experience as invalid as that might be.
Work:
C, C++, Java, Perl, C Shell, Bourne Shell
Pleasure:
C, Scheme
I bet I'm the only software engineer here who primarily hacks PL/M.
;)
FWIW, my PL/M output is relatively low (due to the quantity of documentation and bureaucracy that goes with it and the spagettification of the legacy code), ditto C, perl output is high (mostly for fun) and HTML probably doesn't count. I don't count lines, so I have no idea.
I would give a link to PL/M, but I've only ever seen it mentioned in the Retro-computing museum and I've lost the link to that.
Iain.
Two things:
1. yes i am a lazy programmer, but also a fairly
good one when i do code.
2. I think this whole article/way of judging
programming is exactly why bloatware exists
today. People seem to judge programs based
on how much space they take up, not by how
much they can do. 5 years ago people would
never have believe MS Office could take up
more than 5 or 10Mb.. whats it up to now? 80
100 120Mb? what new things can you do with it?
its bloatwareitus.
-Z
I'm afraid. I'm afraid, Dave. Dave, my mind is going. I can feel it. I can feel it. My mind is going.
LOC is a bad way to measure productivity. consider the case of a language like perl, where one can fit an incredibly large, incredibly complex program into just one or two LOC. thus, although I wrote a hell of a lot of code this past year, I haven't been writing it in perl.
"How absolute the knave is! We must speak by the card, or equivocation will undo us." -- Hamlet: a5,s1
What percentage of the code was written for an employer and what percentage was written for a personal or free project.
-Rich
It depends on what you have to do. As a sysadmin everything I wrote was in ksh, or tcl, with some C hackery to extend the functonality of existing programs. System administration does not require complicated software, most if it is generating or reading some sort of report automatically and for those kinds of things interpreted languages excel. We used TCL becasue my boss, the original author of most of the systems, had extensive background in TCL.
At my new job I've done very little coding at all, and everything I write at home is in perl.
-Rich
*runs*
Scheme! No! AGH!
Actually just the other day I was talking with some friends on how effective the old Scheme interpreter was at making UIUC's NeXT's crawl.
I still get a chill when I see that little purple book.
-Rich
I know that there are a lot of really good american programmers out there.
However, from what I've been seeing is that window IDEs are just getting easier and easier to use.
IS M$ at Fault here?
I see people who are not very knowledgable in programming coming out with functional applications using crappy RADs. Plus I see hardcore programmers just getting lazier and just using the same wizards and RADs (myself included).
M$ windows programming sucks.
"If a show of teeth is not enough, bite
I'm just unable to count them (They are spread over too many projects, and I even don't remember programming on some of the smaller ones)... So, there's no alternative for me! Add one, please!
--The knowledge that you are an idiot, is what distinguishes you from one.
I'm a programmer in the UK and I'm *lazy*.
I see this as an attribute. Being lazy entails
taking shortcuts, doing bodge-jobs (that will
be passed to others for maintainace), delegating
tasks, and anything else that will give you an
easier time.
Don't get me wrong; I'm a perfectionist at heart.
But being lazy is a Good Thing.
Good example:
Rommel (WW2 German General Geezer) used to recruit
`lazy' intellegent men as his top commanders,
particularly because they were the most willing
to delegate. Dillegent, intelligent men were
consigned to junior offer roles as they would
insist upon too much personal control and
responsibility.
Dillegence only goes so far.
Don't Work Harder, Think Smarter.
Thanks for reading; that's my 0.02 Euros
Swamp
LOC is definitely no way to measure quality or productivity, but there's some truth to the story. Many software houses have become so successful that many programmers with stock options have become filthy rich. The result is that the programmers have less incentive to put in extra time and energy for coding. They're rich alreay! Why work hard? There was an article a while back on CNet or ZDNet (can't recall which) which offered that explanation for the recent bloatware proliferation and why Windows2000 is running into so many brick walls.
Of course, that only happens to the programmers who don't code for the fun of it. =)
I was forced to learn PL/I in school. Just after I finished the class they switched to C. Pissed me off.
I use:
Perl, a bit of C,Javascript, Lingo (who0p), HTML (i know it doesnt really count).
Jarod
I don't know about everybody else, but I'm tired of working my butt off and then getting called lazy. Tell you what, I'll go home, and YOU run the system, OK??? Then we won't have a y2k problem, it'll be a y1.999 1/2k problem when it crashes around YOUR LAZY BUTT...
You do not lose the source code for production modules. There is software specifically designed to preserve production code from unapproved changes. The fact is, 30 year old code gets recompiled with new bits added all the time.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
However, both Beethoven and Mozart are considered to be masters of all Ages, with equal fame and respect. Yet, nobody ever would say Beethoven is a slacker. One of the underlying reason is, Beethoven carefully crafted and tweaked his work to make sure they're Perfect. I'm not saying Mozart does not care about the quality, it's just that Beethoven spent much more time on that.
Are you kidding? Mozart was a hacker and Beethoven was a suit. I'd much rather listen to practically anything by Mozart than overblown Beethoven.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
I think that if you're looking for people to work for you, it would be good to include your location, or at least open job's locations.
Good luck.
Hanzie
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
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.
I
have
no
problem
meeting
my
boss'
quota
of
75
klocs
per
month
since
the
space
bar
got
broke
on
my
keyboard
here
at
work
and
especially
since
they
locked
us
code
chimps
in
a
room
together
Perl. Great for CGI and the CPAN library just kicks my ass all over the place.
Actually, I was going to laugh at your for using QBasic... :) But I assume you have a good reason for that.
Hell, lots of us coded BASIC at one time or another.
Damn, where did you go to school that let you code Scheme Freshmen year?
Hehehehe... Good point. I'd like to see a report in some literary magazine - "American Authors Less Productive Writers"...
SQL Error
And I quote...
:|
One alternative is to tap reusable software components and object technologies to improve software development productivity...European IT units at Morgan Guaranty Trust Co. "lean more on using packaged software than we do in the U.S.," which helps boost the Europeans' overall productivity
...is it just me or if you use other peoples modules, classes and objects (that already do the job adequately) you would end up writing less code. The argument of this article has no grounds to stand on.
It even contradicts itself in the end. The last couple paragraphs of this article focus on how shops that reused code are more productive, but the first half of the article tells you that more code means more productivity.
The way I read this article's argument is that...
1. More LOC means more productive workers
2. More productive workers mean better products more often than not (depending on your definition of productive)
3. Ergo: the more LOC the better the product.
...so this must mean that Window$NT MUST the Holy Grail and we should all give up on anything else! Haha...yeah, right.
Ok...back to being lazy and unproductive
mr2
In one code generator table I place:
GUI, "Update * Quote", c?x?, GUI-Update-Quote, STOCK, Current_Quotes|Historical_Quotes, browser
In another table I place:
GUI-Update-Quote, Field, "Company", *.company, c15x1, c60, display, search, primary
GUI-Update-Quote, Field, "Ticker", *.ticker, c15x2, c16, display, search, secondary
GUI-Update-Quote, Field, "Start", *.price.start, c15x3, q12, update, ,
GUI-Update-Quote, Field, "High", *.price.high, c15x4, q12, update, ,
GUI-Update-Quote, Field, "Low", *.price.low, c15x5, q12, update, ,
GUI-Update-Quote, Field, "Close", *.price.close, c15x6, q12, update, ,
With these 6 db table entries I've just told the code generator to make two new routines. One to update current quotes table, and one to update the historical quotes table. With two more DB entries I can place them on a menus. So, how many lines of code did I write in the past twenty minutes? Does what I wrote even count? I've just made two new access/update routines without writing a single line of "code". Or should I count the 2500+ lines of newly generated code?:)
At one time authors were paid by the word. this lead to the saying "Pages and pages of painfully padded paragraphs." The publishing industry wised up and started to pay on book sold. Books thinned out, were cheeper to make, and sold more as they were less time consuming to read. I wonder what will happen with the software industry if they catch on that quality matters, not just volume?
By the same logic, Windows 2000 must be a much more productive operating system than anything else, since it's running about 35+ million lines of code, by the best estimates.
(sarcasm mode off)
--John Riney
jwriney@awod.com
(display "Scheme is the ultimate logic language, Intercal is the ultimate unlogic language and OISC is the ultimate simple language. Well, I coded some functions to Scheme that emulate Intercal and OISC, so now Scheme is the ultimate logic, unlogic and simple language.") Well, Intercal is still unlogic -- PLEASE COME FROM (69) PLEASE ABSTAIN FROM STASH (42) DO .1 - ".1$'&:51~"#?1$!12~;&75SUB"?'V.1~ .2'$,&1SUB:5~#33578"'"'"~'#65535$"?'V#&85'"' PLEASE DO .2 >- !1$"&';?79SUB",&7SUB:173"'~!?9$ #8196'"'~.1"$.2'~'#&5$"'#1279$#4351'~#65535"' P.S: OISC = One Instruction Set Computer (Slashdot <TT> dont show CR)
--
"Basically the message is: Steal It!
Mmmm...Scheme. Seriously, Scheme *is* a fun language. Some of my fondest coding memories come from my freshman year Scheme class. I've since moved on to C, C++, some VB, Javascript (I don't usually count that or HTML), and a small amount of Perl and shell scripting.
But given the choice, I like to code in Scheme or Lisp, or C++ when those two are insufficient. After two years of not using Scheme for any classes, I found an AI class that uses Lisp. I'm happy.
Only C/C++ and the OpenGL API.
I've used VB in school (it bites) but no way would I ever use it if I didn't have to.
The only people who don't write a lot of lines of code are VB programmers b/c the program does it for them.
This has got to be the absolute most idiotic and ridiculous use of statistics I have _ever_ seen.
Statistics alone are just bad. You can generate any type of statistics you want to illustrate any point that you want. By no means (and I mean, NO means) does that validate the point being illustrated.
I mean, come on!!! Lines of code being used as a measure of productivity!?!?! What a crock!
This story looks like something that belongs on The Onion .
I would guess I was just shy of 20k lines of C++ and Java (with some C sprinkled in for old-times sake).
However, it appears most people here are including scripting with programming, in that case I am WELL over 20k using awk, shell, and tcl/Tk.
-- Keith Moore
This sig is the express property of someone.
Those numbers (8k-16k lines / year) sound awfully small. I don't see how I could program more in just a few spare hours here and there than a full-time programmer does.
So i'm curious, why do all the programmers I know spend 60-100 hours a week at work? (myself included)
Further, that paper takes no account for the quality of the code - I can write a functional hack in a few hundred lines of code , and then have to rewrite it to do something a little different. OR I can designe one thing, which is
abstract enough to do all of what i need. It takes less code, but more time to do correctly? Does this make me slack?
Even if LOC was a reasonable way to measure productivity - is it reasonable to count Generated LOC, or just "handwritten". For example, I hate writing CGI scripts, and i'm "lazy" so we (fundsxpress.com) wrote a system that inlines perl in html (like many others) and builds CGI scripts from that. On average it generates ~30k lines per "pile". No one "wrote" that code, but it exists all the same.
I agree to some extent. At first I looked a the people i've interviewed/hired, the people i know who work at other companies. It occures to me that our hr people throw out about 90 of 100 resumes based on some simple filters. Of the 10 that we call in , lets say they all come in - about 1/20 will leave before finishing the test because its "too hard" (its not hard at all). About 50% of the rest fail the interview, so leaving about 4.5-5.5 people. About 2-3 of them will just not fit in, and we will try to hire 2-3 people. At best this suggests 5/100 people are worthwhile (not by anymeans a solid, accurate, or reasonable statistic). However even as a rough guess, it says something about the other ~95 people.
The "filters" arn't anything special , we try to look for people who don't look like code monkeys. The test asks questions like "write a function in perl to swap two variables". Not hard, but shows a little about the person.
So assuming that about 70 of thoes 95 people really are just worthless as anything but code monkeys , there are infact a lot of bad, lazy, slow programmers.
- The "right" solution to a programming problem often requires much less code. Not long ago I reduced a billing subroutine from 1100 lines of code to just over 150, and increased the speed of that process by a factor of 4, with higher data reliability as well. It took about three days to figure out the logic, but only an hour to code it.
- In another project, I churned out about 3,600 lines of good foundation-class type C++ code in about 10 weeks. As I am working on projects now, however, I simply reuse the components created as part of the library, which allows more rapid development, but requires less new code.
- State of the art programming tools and languages require less hand coding and lower LOC counts to achieve a given result.
Am I therefore less productive? I don't think so, and neither does my boss. While I have met a few programmers I would define as slackers, most of them didn't last very long, are low paid, and marginalized by their own low quality work....Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Worse still, LOC is a horrible productivity measure esp when comparing brace styles: if (thing) { stuff; } versus: if (thing) stuff; the former being 4 times as "productive" as the latter.
Hey guys: the one true brace style is not as productive as other styles. ...Grin...
-- Perl Hack, Web Hack, SQL Hack, Guitar Hack
DUH.
if (thing)
{
stuff;
}
versus:
if (thing) stuff;
-- Perl Hack, Web Hack, SQL Hack, Guitar Hack
I started learning C about 6 months ago amid my classwork and such. I've not had real need of it in my studies, so I've not been working very hard at it, My grades are more important. To me that one-liner is VERY confusing, and the only reason I understand it clearly, aside from the previous posts, is that I tried to upgrade my C libraries when I was going from Linux 2.0.36 to 2.2.2.
I can read cleanly written C code, but I have difficulties when unusual formatting is used.
Laugh, it's good for you!
Now Americans have a monopoly on honesty ?. Based on your experiences with a few foreign programmers you arrive at that conclusion. I note you did not smear the one or two countries you were in contact with, but rather all foreigners.
Based on this comment I can conclude that you are a f_cking moron, as only a moron would arrive at such a hasty generalization. Based on my exposure to Americans I can conclude they are arrogant f_cks, convinced of their own superiority. But I have realised that everyone is different, and while a system may be broken the people usually are not.
But of course I do not believe in making or spouting stupid generalisations.
Woe be on to them, all who rise against poor people, shall perish in a the end. Buju Banton
At work I live in SQL (inside FoxPro, sadly).
At home, C and if I'm having an RMS kind of day, Lisp...
paul
Silly Rabbit, sigs are for kids.
I was startled by the few avialble lines of code.
I am a physics graduate student who occatioanly needs to code (oh.. and I teach a computational physics lab class), but I spend *perhaps* 2% of my time codeing and in the last year I made just under 10K lines of debugged and well commented code. I don't understand how a full time professional coder could possibly produce less than 40 or 50k lines/year.
Write everything in assembler!!!
Really, LOC is probably the worst measure of product size or productivity that there is. The effect of 4GLs is to try to _reduce_ the number of lines of code that the programmer has to write to do a task.
So, maybe we should take this as a good article. I mean, we're doing more with less lines of code!
Besides, I hear writing the code for a project is the easy part. The requirements, analysis, planning, and design are what eat up most of the time and demand the most skill. Perhaps we should define productivity as lines of pseudocode???
Oh yeah, maintenance eats up tons of time too, just to change a few wrong lines of code.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
What if you've been a programmer for, say, ten years and you wrote a ton of reusable code at the beginning of your career, and now you're just reaping those benefits and plugging in code?
Another good poll would be "How fast do you turn around new development projects?" Would have to be delimited by user spec to 1st alpha or something since true rapid prototype and re-users never have "final" product code...
-- "In order to have power, I must be taken seriously." -Mojo Jojo
If you write a compiler, does the amount of
code it prodcues (for, in my case, a C generating
compiler) count.
anyway - I go by number of ;
anyone want to compete on a number of *generated*
lines?
Yeah, we're lazy. But I once heard that if you want to find a more efficient way to solve a problem, give it to a lazy person....
Yale lets you code in Scheme in freshman CS class. Great fun too! Learning about infinite streams after only two months of undergrad CS was a definite mind-opener. aahhh, the memories. It was also fun being among the few in the class who could debug the code :-)
Abelson & Sussman rock hard.
...for the last six months of my current project: ~16.3K lines of Java. That's on a contract job, involving a lot of requirements thrashing (ergo, a fair amount of code thrown away). But the thing's about to go to code freeze, with adequate quality (i.e. no showstoppers and good usability).
So I guess I'm running about double the productivity of the average worldwide programmer. Only problem is, if I worked over my code I could probably get rid of a few hundred lines here and there, making it cleaner & more stable in the process... would that make me negatively productive?!?! yeah right....
Hey Rob, we need a <CODE> tag here!
No, we need < and , etc to work again.
Once you have those back, you can get by quite fine with the [TT] and [/TT] tags to get nice code... (of course, those should be angle- not square-brackets there).
Before the &xxx; tags were mangled, I used to be able to submit quite passable-looking code to Slashdot.
--
- Sean
It's a fine line between trolling and karma-whoring... and I think I just crossed it.
- Sean
But I guess this was a good chance to comment on a perhaps not-so-uncommon mistake and frustration.
Anyways, I not primarily a programmer. I only had maybe 2000 lines, but my job is mainly system and network administration right now.
A seemingly bug-less program contains a major bug
s afety/www/ d s.html
if the user interface is badly designed.
Aircraft have crashed because of this.
Lines of code _cannot_ be a valid measure of productivity.
Most programs are buggy because they are badly
specified to start with.
Useful URLs on Specification and Formal Methods:
Peter Ladkin's homepage
http://www.rvs.uni-bielefeld.de/~ladkin/
Software Safety at UofW
http://www.cs.washington.edu/research/projects/
Formal Methods Virtual Library
http://www.comlab.ox.ac.uk/archive/formal-metho
This brings me back to a comment I made in a job interview earlier this week (by the way, anyone in the DC area looking for a good software engineer?) when the subject turned to coding style. I made it perfectly clear that when I write code, it's with ease of readability in mind, not ease of coding.
:)
Maintenance eats up far more cost than coding. be nice to your maintainers.
Sounds like most ppl think LOC is a bad measure. Must say I'm inclined to agree. Personally I wouldn't have a clue how many lines I wrote last year - I measure my productivity in functionality I've implemented. And whether the client is happy. As a project leader my measure is how much revenue I've raised in new contracts.
Sooo..... who's got suggestions for a productivity measure that's more reliable than LOC but more quantitative than mine above??? Could make a good /. poll too. I'd say /. readers are among the most productive programmers out there and we probably represent a fair swag of countries.
Long ... long ago in an old stupid culture there were many ancient geezers in Government that paid per KLOC and the king wore new cloths every day. These foolish folks never knew FLOC (Functions per LOC). I remember this story from history, I believe it was really true inthe past.
Anyway the moral of the story is a creative smart short FLOC will take longer to make than a bunch of stupid LOC, but you always get something that functions at a far better price.
So, sounds like a statistical lie, due to stupid data collection methods/procedures/functions.
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
Dave,
..., but that was two decades, or more, ago atleast). I know alot about a few things (switching ...) and a little about many things. I just tell folks I'm a Technology Assistance Professional (TAP), because they never understand other explainations of not quite a programmer, network planner/analyst, troubelshooter that can do math but does not have a degree ....
Yep, you are right, management (with Limited/No Technology/Programming/Engineering knowledge/experience) folks are very strange and funny in a miserable sort of way. Many are a wasted pay check. Around here we call'em View-Graph Engineers (Good Briefers) a/o Career Managers (Promotion Focused). I have also heard them call me and my colleagues worker-bees and pack-mules (obvious reason and both are sterile on decision making). A recent silly for me (from management) was teach others linux next month (my first reply was I just bought linux 30Mar99, NOT 01Apr99), about 30May99 I'll have them convinced that maybe 30Sep99 would be a good date, but I'll still be forced to put on a class by 30Jul99 (if I'm lucky). I laugh (at work) more that most folks believe, and management just figures I'm a happy (though a little crazy) employee (True, I am a happy employee or I'd be gone, but they don't know/believe that?).
I'm not a programmer, more of a WAN integrator (Okay I did write a couple lines of some hex-code PL, and a little double-digit cobol and
Anyway I hope that slashdot develops a management topic, because we need to either get rid of the fools or get'em trained for a real job.
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
Similarly, i've been working for about a month
on a large project where I need to graft a new
feature into an existing code base (that I know
nothing about). I've managed to add ~1000 lines
in that time; the rest of the month i've had
to spend analyzing how to manipulate the
existing code to make it do what I want.
Using MS Visual C++, (sorry, but it has to be cross platform around here...) A single user interface that I can design in 2-3 hours comes out to about 1,000 lines of code with a splash screen, an about box, etc... In Unix, the same thing can be accomplished with Tk libraries in about 100 lines of code.
So, I write the program for Unix, and use 100 lines. The guy sitting next to me ports the program to Win95, and uses 1,000 lines, and half the time, because I have already made all of the components cross-platform. Who just did more work?
And how long is a line anyway?
cout
So, the above is 4 lines or 1?
cout
How about now?
cout cout cout cout
And just to be obtuse, one more example:
cout
Hmmm, change my answer in the poll. I guess I wrote over 20,000 lines last year, I just did it in 6,000 lines.
Hamnrye
/*Gather up the gold you found you fool, it's only moonlight*/
Really LOC is an innaccurate way of showing productivity. I could make a given language print Hello World! in 12 lines (one letter per line) or in 1 line. The fact that american programmers produce fewer LOC than others might just mean we produce more efficient code...
- AMW
Assembly. I'm moving to machine code later in my life, but assembly is as high as I go.
How do you the nationality of the posters?
For example, where am I from, mail me and tell me...
balrog@swipnet.se
I'm sorry but I fail to see how a monstrosity such as visual basic could be important whatsoever. And what the hell is J++? I'm guessing it's M$'s proprietary java. Unless you want to be stuck on windows for the rest of your life I'd suggest avoiding any of those kludges.
There's plenty of cross platform languages that will do everything and more that microsoft's solutions will do. C/C++, java, perl, tcl to name a few. Learning a microsoft specific language is relegating yourself to enduring whatever they feel like dumping on the developer community in the future.
Actually, it would make you lazy. Although it isn't necessary to turn hello world into 50 lines of code, it also shouldn't be one line.... If you leave it on one line, some people may have a hard time reading it and understanding it. Then you have to go back later and make it legible for everyone, and that wastes time. Makeing you not lazy, but inefficient.
Actually, it would make you lazy. Although it isn't necessary to turn hello world into 50 lines of code, it also shouldn't be one line.... If you leave it on one line, some people may have a hard time reading it and understanding it. Then you have to go back later and make it legible for everyone, and that wastes time. Makeing you not lazy, but inefficient. I'm not really sure wich is the greater of the two evils. -- just my two cents --
does that include today? Or just the last 365 days??
We are lazy programmers because we produce less lines of code? What bullshit. Geewhiz.. pardon us for thinking about what we're doing enough to write it efficiently.
Sure if you have to rewrite something 50 times because it doesn't work, or doesn't work properly then yeah your # of lines is going to be greater.
Why does this poll make us slackers? We work smarter. Not harder.. w00t!
What a stupid test.. jeez.. They can shove the poll up their a$$.
That's about on par with the tabloids. Bat-Boy lives!!
--- lokai
Python.
Maybe you're making $25K because you CAN'T FREAKING SPELL!
Sheesh. That'll teach me to type and eat at the same time. I'm actually amused that there weren't more errors in my post. But who really cares how screwed up my english gets so long as my code is clean and functional and everyone's PC's are still running. I'm not writing grants here, I'm fixing PC's and keeping the network alive. Thanks for the slam though, nice to know someone out there is still decent enough to be an anal retentive moron. And while we're being petty and stupid, did you really mean to say, "Arrrrrggggggghhhh!!!!" 'cause that would sound rather wierd. Kinda like a person taking a short fall and then gurgling and hissing on the ground. Perhaps you meant, "Arrrrrrrgh!" And do extra exclamation points really make you louder? Lemme try, "Either get back to the subject or shut the hell up!!!!!!!!!!!!!!!!!!"
Gee, that worked.
Two freakin' spelling errors and people jump all over your back. Ok, ok, the "decent/descent" error was italicised and therfore rather obvious, but once again...sheesh
Once more unto the breach dear friends...
Damnit. Typo.
...was italicised and therfore rather...
Should be: therefore
*sigh*
Once more unto the breach dear friends...
Then find another job. It's not you who should be irritated by them, it's they at you for doing what you do for such a piddling wage and bringing the pay average down. It is not immoral or disloyal to leave a place where you are underpaid and overworked.
Actually I'm in the process of doing exactly that (finding another job that is). And there are certain benefits to the position that I'm in, namely that I have a good deal of lattitude in my schedule and projects, and that as I currently work for a medical institution (a school actually, hence the lower than standard pay) I get absolutly amazing health/dental benefits.
As for job-switching...yes I am young(ish, 22) and forced to fight a little harder for work simply because I don't have a degree. Which, while understandable from the employers point of view, unfortunatly makes it supremely difficult to prove my abilities when I can't get my foot in the door. And even years of experience in various entry level tech positions and a year at an ISP weren't helping. Shiny big names work a lot better. Which is why (after a lot of that job-switching crap) I've wound up at my current job. The name (and a couple of years attached to it, along with glowing testimonials from my boss(es) ) should be enough to skip up to a more appropriate pay scale elsewhere.
Basically I've got a plan and am working on it. I was merely (in the original post) trying to point out some of the inherent imbalances in the modern corporate structure where-bye under skilled (but degreed) workers get paid a significantly higher amount for one hell of a lot less work. This kind of "look at all the pretty letters" mentallity is the same that causes the usage of flawed statistics to prove what you want them to, "Look I told you all these good for nothing coders were lazy, let's get rid of these three, save the company some money and give ourselves a raise."
I'm not being cynical. I see this kinda stuff every day.
Oh, and just to avoid potential flames; I'm not knocking higher schooling, just the complete morons that manage to make it through and clog the workplace.
Once more unto the breach dear friends...
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...
LOC advantages:
- easy to count
- can be used for historical purposes
LOC disadvantages:
- nothing to measure actual performance of the
code
- coding is only 1/3 of any given project
- dependent on language - I used to pound out
100+ lines of COBOL a day no sweat, can't do
that in C++ and actually do a good job.
To me, the important problem and what could well be throwing off the numbers is the coding vs. requirement/analysis/design/testing steps. Software factories pound out code, nothing else. The rest of the work is done onshore. You're only measuring a small part of the job (just generally the most fun part!)
"It was me against the world, I was sure that I'd win.... but the world fought back, punished me for my sins" - Social D
However, both Beethoven and Mozart are considered to be masters of all Ages, with equal fame and respect. Yet, nobody ever would say Beethoven is a slacker. One of the underlying reason is, Beethoven carefully crafted and tweaked his work to make sure they're Perfect. I'm not saying Mozart does not care about the quality, it's just that Beethoven spent much more time on that.
One may argue that things are different in the programming world. Yes, indeed. Here, "laziness" is actually considered a skill to master by many programmers. (Most of the time this has to do with Perl.) Often, it is the lazy nature of many programmers to motivate them into code reuse and optimization (and debugging and testing also, in some extent, to save their lives before the software crashes in front of the customers and get fired). I mean, who would like to type a 200-line code block over and over in the code base, each block only slightly different than others? We probably wouldn't have programming languages, and continue to program in 1's and 0's only, if we're not lazy, let alone the stdio.h, or even gcc itself!
Using LOC to measure productivity is then essentially as effective as measuring time spent sitting in the cubicle, which, as we all know, is useless. Just as useless as measuring MIPS of the CPU (as seen in Ars Technica's article about benchmarking).
That said, if LOC is used as "THE" measure of productivity... I guess many people are more "productive" in email + newsgroup + /. than in code. And, if it's actually considered the measure of productivity, I'll put in snipplets of "Hello World!" program -- 500-line version -- in my current code (it's just a matter of cut and paste).
work: PowerBuilder (and it makes me want to shoot myself)
PL/SQL (feels a bit more like programming)
home: C, once in a while
java, less often
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.
Kick ass! Here I thought I had to write robust, elegant code to be productive. Now a CNN reporter (I didn't see the name -- was it Knuth? I heard he's working for them now) tell's me it's all about the number of lines of code. Thank god! Time to double-space my comments.
"Whatever happened to fair use?"
-- Duff-Man
I don't know LaTex, but rule-of-thumbs for turing-completeness are (that I can think of):
-- some mechanism for infinite storage (a stack, a natural number with no upper bound, a malloc equivalent, and arbitrarily big string, etc.)
-- some mechanism for decision-making or nondeterminism (an if statement, conditionals, etc.)
-- some mechanism for infinite recursion or infinite looping
-- some sort of "thread of control" including a start point and and end point
Is that everything? I remember discussing this with a CS prof back in college, and those were some of the criterea we brainstormed. An easy proof (for LaTeX) might be to try and code a deterministic semi-Thue rewrite system for it (See the "Handbook of Theoretical Computer Science," volume B chapter 6), which can basically take the form of a recursive search-and-replace function with several search/replace pairs.
Hope this was remotely helpful. Good luck!
"Whatever happened to fair use?"
-- Duff-Man
You could say that according to the LOC we are twice as productive.
That is all
http://www.braveidea.com/ABCMetric.html
ABC is a metric of code size/complexity that counts the number of assignments, branches and conditionals.
BraveIdea has got ABC calculators for Java, C and C++. One could probably work one out for other langauges as well.
IBM used to pay it's coders by how much code they would write... not how efficient it is... maybe us american coders just code better? ;)
This has got to be one of the stupidest reports that CNN has ever run. We found out that basing metrics on the LOC produced sloppy, inefficient code. Today, I removed 8 lines of code and replaced it with 2 that do the same job. Does that make me lazy? Its unreasonable to use the LOC as a measure for productivity. I can get rid of all of the include files and subroutines and functions that I call repeatedly and throw that code into my simulation. That would EASILY increase the LOC by a factor of at least 10. Would all that redundancy be better? I mean, after all, at least CNN wouldn't think that I'm lazy, or "fat and happy."
Maybe a better article would be on the press reporting on things that they have no clue about, so they sound really really ignorant when they write an article. Who knows?
-- toolie
How many KLOC do you write a year?
Anyone else think of any more questions that are hard to measure and people lie regularily to when answering?
Despite the (repeated and obvious) mention that LOC doesn't mean anything, who the hell answers the questions accurately?
Ususaly when you see those surveys about which country (province, state, whatever) has sex the most often, the winner is usually the country with the most liars per capita.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
I agree with most of the posts here on the fact that using LOC as a productivity measure is stupid and inefficient. But what I find even more stupid is generalizing the coding efficiency based on the code author's nationality. Does it truly matter which country produces the most LOC or even the most efficient code. Is not the goal the same for everyone anyway? It should be.
That comment about the Frenchman is very ignorant, and I would really like to see the poster put his money where his mouth is. I am willing to bet that there is a numerous amount of Frenchmen that would be able to do what the poster does. Who knows, maybe they would do it twice as well too.
So when this poll is done can you calculate the average and post it to some national news people. Of course you really need to remove all the less than 1000 votes, because most of them are from people who really arn't programmers (like me :( )
The original survey was a survey of "programmers" so to make the survey valid you should remove all the non-programmers. (and its kinda impossible to tell the to not vote)
If you have a decent compiler, it shouldn't matter.
DrLunch.com The site that tells you what's for lunch!
Get a new job and quit whining already. If you can't get a job that pays more, then the market had decided that you aren't worth any more than you are already making.
DrLunch.com The site that tells you what's for lunch!
I'm in the middle of getting a BS in comp sci and I was just wondering what languages most people actually use, whether in the workplace or in their academic lives. What people actually use to get work done is not something we learn a lot about in college.
The mainstays: C, Bourne, Java, Tcl, Perl
The every now and then's: C++, VB
The old standbyes: Scheme, ML, QuickBasic, Pascal
The application languages: HTML, PostScript (yes, raw), make, sed, CSound (orc, sco), Guido, CAL, QAC, and at least a dozen more I can't think of offhand.
Div--
But my grandest creation,
As history will tell,
Was Firefrorefiddle,
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.
Is there a difference between
if( foo )
bar();
else
bat();
and
foo ? bar() : bat();
No - nothing except $9.00.
Work: C,C++,Perl,Java,Javascript, HTML (But that don't count) PL/SQL (I Think that does.) Home: Ahahahahahahaha! Like I'm gonna code at home! For fun? I gotta sit down and get my breath, that's funny.
I wrote between 15k and 20k Lines of Code last year as a sys admin and on a part time basis for fun. I spent most of the year on a project doing network design, that did not require any coding. LOC is a poor way of determining productivity (unless you work in Redmond). How do you count a perl one liner that works great vs a buggy 50 line program in any language?
Measuring by lines of code is dumb. Depending on your style, you could end up with hundreds of lines difference for the same program. And besides, more lines of code isn't necessarily good -- it could just be inefficient. We don't grade surgeons on the number of incisions they make do we? And we don't grade painters based on the number of paintings they paint. Number isn't everything; quality is much more important.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
Anyways, looking at all of this. Firstly, why so little code produced?
I've just had a look at the amount of code I have written in the last three months. About 2200 lines of SQL, 2800 of Perl and 400 ish of C. That makes me pretty productive right? Errm, no.
When I was coding on university projects, I could code about 200 lines per day. If I code at home now I can so 400+. Thats 400 lines of code complete, debugged and ready to go. So how come the low output rate ( even though I can code faster now )
Two words : Mission critical. We write code that deals with MGT money, and lots of it. If your code is wrong, it costs. If money goes to the wrong place, you lose it -- or it costs money to retrive it. So it must be right. And people are not just going to take your word for it. You must prove it.
That adds extra testing time onto any program that you write. There is much more liason with people than you have at home. At home you discuss things with yourself, not with someone on the end of a phone. Think loopback compared to ppp. You can't just su root and install it. You must ask someone else, get signoff from end users, technology heads etc. Why ? Because its mission critical.
Add in the time spend answering user queries, and the time spent testing vendor code -- yup, thats tested completely too ( remember Mission critical ) and there goes the rest of the time.
Do Europeans use more packages ?
The comment about using packages is rather more high level in Europe than code generators. There is a much higher tendency here ( especially in Germany ) to buy in off the shelf third party packages, and adapting them, than writing in house custom applications. Its a good way to work. As my SC2 lecturer said : "Don't spend any time writing code that somebody has already written". On the floor where I work, its all code bought in from outside with minor adaptations in house. Interestingly, this should mean more time testing, and less time coding ( so should reduce the average EU programmers output rather than increase it )
On the "Who is more productive question"
At the risk of being flamed into oblivion, I would also say that there is a feeling amonst the people that I work with that American programmers are less productive than European ones. Indian programmers have a reputation for being fast, but not very imaginative. That's a view from the trenches and is not based on any numerical measure. Just the opinions of maybe a dozen programmers using a dozen different systems over here.
Incidentally, MGT have just announced their new global development center in Glasgow ( Scotland ) -- and that's not a trade secret by the way. This was where they felt they could get the most bang per buck. Ie. Most productivity at lowest cost, and they looked all over the world.
The standard disclaimer applies. These are my views, and in no way represent the views of MGT. I have not been authorised to speak in this debate by MGT.
Isn't less code that does the same work better?
Sig missing. Reward.
It's me... It's me...
Pretty much all Java (for the last 2 1/2 years). Other than that, smatterings of shell script and elisp stuff.
/. readers seem to hate Java so much - I do all enterprise work and it's really going strong in that market.
I'm not quite sure why many
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Measuring the work done by a programmer by the number of lines of code written is like measuring the quality of a piece of literature by its length. Is Proust's _Remembrance of Things Past_ really thousands of times better than Blake's "The Tiger"? Is it even reasonable to make the comparison?
For some reason, managers tend to think of coding as being akin to shoveling coal or cutting lumber, in that they expect it to be measurable in quantifiable terms. However, quality is the central issue in coding, not quantity.
I recall an old rumor that IBM used to pay programmers by the line of code. For some reason, their software became a *leetle* bit bloated.
That's "Mr. Soulless Automaton" to you, Bub.
LOC/year is a stupid measure of productivity. If I write 5000 lines of code a year, and all of them are correct when I deliver them, does that make me half as productive as someone who delivers the same program in 8000 lines and then must rewrite 2000 lines to fix bugs (total of 10KLOC/year)?
It's typical of Suits to force a quantitative measure on something that's fundamentally unquantifiable so that they can measure and judge and compare without actually *understanding* what they're talking about. And it's sad when these bogus measures are used by management to promote people or by journalists to prove a point that's not there.
I used to code BSD style (and before that, GNU style. Love the FSF, but their indentation style causes nightmares.). I switched to 1TBS because there are only so many lines of code you can fit into an emacs buffer. Every extra line helps.
:) Until I get that infinite monitor, though, I'll economize where I can, and live with the slightly less pretty 1TBS.
I still think that BSD style brace placement is better aesthetically, and if I ever had an infinite monitor, I would revert to it.
You're a suburbanite.
Those 8,000 lines were almost all Perl. How many lines of C to do the same thing?
Feel free to multiply by 5
Which means absolutely diddly-squat in the really-real world.
I'm a UK coder, and I would like to point out that our US coder's style results in a lot more compound statements being used than I would write myself.
Sometimes this may result in code that is harder to follow/debug.
You need more metrics than LoC to evaluate the 'productivity' of a programmer - and I think the true formula must involve some sort of measurement such as: ;0)
pizza's eaten in office / time
The only thing you really get by measuring LoC is a minimum figure for how many times the enter key was pressed.
Jim
software engineer
ubik.net
Yes... and many years ago at a TUG conference a guy from MIT gave a presentation that described
a basic interpreter written in TeX.
Yes I agree loc as a benchmark is ridiculus. When I programmed CGI-Scripts for a company in perl one year during school I wrote 100's of lines of code a day. Becuase it was easy. Not to bilittle my task. I worked on serveral projects at once. I also was incharge of system scripting.
/. all subscribe to the hacker ethic and really enjoy coding. I know I do. But the survey matching loc was just an indicator a broad slice. Our we Lazy coders? no I don't think so. Our there Lazy coders in the US? You better believe it. Come and work for the company I am about to leave. Most people just have a job cause it is good money. They would not even dream of writing code outside of work. It just isn't fun for them. So they drag their feet. I think our state schools producing degrees in computer science for people who are half wits is a bigger problem. Companies who need people just hire degrees cause they are desperate. Therefore people know they are going to have it easy slack off and surf the web. Or they over estimate projects for each other and milk the clock.
Never the less I think the type of people who read
Just my opinion though I could be wrong.
~pearcec
Scary. I wrote > 10000 lines of python in about 5 months, while I was working on other projects too.
I must be insane.
I was afraid if I replied to this thread, I would be the only COBOL programmer! Made a lot of money 'fixing' all that y2k 'infected' COBOL source last year, the rates are double if you waited till this year. They'll go up even more if I have to come back next year and fix something some else missed.
Planning on retiring the year after that!
Oh, and I didn't 'write' any lines all last year, only changed ones that were already there (about 10,000)
I thought we stopped counting LOC in favor of Function Points a long time ago when measuring the size of a program, project or system?
That seems like it would equalize the language/style/bloat factors being argued here?
I hate to sound racist or anything, this is just my personal experience. Of all of the non-natives that I've dealt with, only a very small few were competent programmers. The rest wrote pure crap code. Mountains of it that I had to debug and rewrite after their contracts expired because it didn't work. These guys had Masters Degrees in C.S. (obtained in his native country), but their code was just horrible. I'm a C.S. drop out, but I know my code is a lot better than theirs was. They would come to me with *basic* questions about things like linked lists and syntax questions.
:-)
What can we expect from a journalist anyway? He probably gets paid by the number of words he writes, and I bet he can fit a very very very very very very very very very large number of words in when he needs to.
--- A Jesus Fish eating a Darwin Fish only proves Darwin's point.
The majority of non-natives that I was exposed to were from the middle east, not that I'm try to stereotype programmers from the middle east; This has just been my personal experience.
Bright people are few and far between, no matter what part of the world you look at.
--- A Jesus Fish eating a Darwin Fish only proves Darwin's point.
-the best implementation of BASIC ever made.
Believe it or not, MS is best with making BASIC. Lets see... C64 Basic, Applesoft BASIC, BASICA, GW-BASIC - all by microsoft. And I have used all of them.
Then I found out BASIC sucked. After I became enlightened by structured programming...
So now I am figureing out C, little at a time. At the same time messing with AUTOLisp at school.
NOTE: I have not had a single programming course.
It is impressive of what some REALLY hardcore Basicers have done with a language not designed for it. Like qbasic readers for
VB sucks. I have used BASIC long enough to know this. People without ambition spend way too much time dragging about boxes and making animations with bmp files (or is this just me?).
It is this one thing that MS does do well. Or used to. VB really sucks. Just wanted to that again.
BASIC is a programming language. Perhaps one of the oldest still in common use (picking off bits of others along the way.)
Okay, you can flame me now.
--
I'm just finishing my master thesis, which revolves around a 1172 lines long Perl script.
At my faculty, we're pretty much free to use whatever language we like for our master thesis, in the undergraduate courses they can choose between Java, Pascal, and C(++).
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.
I can write Fortran in any language
In "Triumph of the nerds" this is commented on quite effectively by Steve Ballmer of Microsoft (Feel free to read in "The Evil Empire" for "Microsoft"). In the very early days, when MS was writing DOS (OK to say "re-writing") for IBM's new PC project they butted heads with IBM many times about how many KLOC were in the current package. MS's point was that as you find more efficient ways of doing things, and learn to reuse code, final KLOC goes down.
One additional observation... The more code you have, the more opportunities you have for bugs. More code to filter through means more work finding coding problems.
How many KLOC are there in Windows? ;-)
Programming is like the standard calculus area problem. Take a big problem and divide it into as many little problems as you can. The sum of all the little solutions is the sum of the whole.
From that thought we can surmise that KLOC can be used as an indicator of the size (area) of the problem which had to be solved. Based on KLOC I can only guess that MS has a lot of problems to solve. ;-)
D. Keith Higgs
CWRU. Kelvin Smith Library
My office has been taken over by iPod people.
Yes. I looked at only a few of my projects from the last year. A rough count gives me 20k. I regularly write more than 1500 lines of code in one day. Watch me be accused of writing bad code now. Oh well.
I like the quote :"My programming staff are 9-to-5ers". What is up with the IT industry? In what other career is a 40 hour work week a sign of laziness? Since when is going home at the end of the day a bad thing.
The comments by Mr. Yourdon about people being burnt out after years of 70 hour work weeks are amusing. I guess American programming productivity would decrease if programmers started putting in normal, reasonable hours.
"If it's a bad idea, trash it. If it's a good idea, steal it and release the source code."
--
"This isn't the post you're looking for. Move along."
Writing more lines of code doesn't make you a better programmer. It does make you a different programmer. This article doesn't scratch the surface in terms of what the actual differences are between US and non-US programmers. I was wondering if anyone with direct experience could talk about what those differences are, and how they lead to different numbers in LoC?
Preferential Voting: easy as 1-2-3
How about one-liners :-)
Say you spend 4 months finishing this just too great one-line image editing program in perl, and then discover you get paid by the line..
find /m7/dev -name *.ec -exec wc -l \;
This tells me (well after adding it up it told me) there are 27,247 lines of code in my devel directory. Of course I use the modified Allman method of coding c
if (X=Y)
{
}
dbschema -f all -d dbname | wc -l
returns the count of lines in all of the stored procedures (14,990), but how do I count the time and effort in building a 300+ table database?
How do I count all of the code that has been scraped/rewriten? Is a comment a line of code?
Sigh.
Java and (yuk) a little bit of asp...
So help me, the only comments in the code were used to "block out" unused lines. For every 5 lines of working code, there were at least another 5 of commented-out code where things had been tried, not worked, and left in the source.
Save the whales. Feed the hungry. Free the mallocs.
So after busting my butt for years, some group comes along and tells my current and future clients that I'm lazy and overpaid?
As so many people have pointed out, GOOD programmers try NOT to write many lines of code. The whole fscking point of OOP is REUSE.
I'm being criticized for paying attention to non-code activities like design, specification, and finding the most efficient way to do the job? HELLO -- GOOD software developers spend MOST of their time on these activities!
Call it programming, developing, software engineering -- the job is about THINKING not TYPING.
If you want a TYPIST, I suggest you hire someone who went to secretarial school.
I don't put in enough overtime? I'll be sure to remember that on the next Sunday I'm working to meet a deadline. Who are these people to suggest I'm "lazy" on the few weeks I only work 40 hours? Last time I checked, THEY ONLY PAY ME FOR 40 HOURS A WEEK!
Save the whales. Feed the hungry. Free the mallocs.
I have NO IDEA how many lines of code I wrote. I know it's gotta be a ton, because I do a lot of assembler. The other thing is, I'm the optimize/debug guy around here. People hand me code, and I make it better. I just finished going through about 60 - 80 thousand lines of buggy fortran, but didn't actually write many lines of code. how does this count?
Calmacil
I can't seem to face up to the facts, I'm tense and nervous and I can't relax... --Talking Heads
LOC is, however, a nearly useless way to measure productivity. Line churn as a work metric encourages inefficient coding. This has been demonstrated in earlier studies. The better way to measure things is how well you are hitting your project objectives and are you staying within the timeline. This requires proper planning at the outset and good project management throughout... which damn few places seem to do. That is the REAL problem with software development in America.
This is all IMHO, but then again I've been doing this for 13 years so my oppinion must be worth something by now. ;-)
Thad (who has never missed a coding deadline but has no idea how many lines he has churned out)
The Bolachek Journals
you'd think with M$ programmers being in the US they alone would have accounted for a huge chunk of that with several million lines of code in each version of windows alone...
not to mention my college, which requires ~10,000 lines of code a year from students (mostly because of the year of COBOL). I guess we are just above then... I wonder if they will try to commercialize that somehow...
herrmm.. let me see here... /home/rick/src | awk '!/.*:$/ && /./ && /.*\.(c|asm|pas|cc|a11|tcl|sh)/{print}`;
for file in `ls -R
do cat $file | wc -l; done
Rick - Professional Linux User
The LOC/Year measurement is not even valid in today's environment. As a programmer, I spend more time fighting with the OS, the tools, debugging, figuring out the intricacies of C++, figuring out how to hookup third party APIs/Components/Libraries, redesign, rewrites, documentation, trying to cleanup and improve the code for maintainability, code reviews, balancing marketing requests vs. what is technically possible, etc... etc... etc...
In other words, American Programmers don't just sit in a cube and hack out code 40 hours a week anymore.
Of course someone way off in another country can create more LOC, when all of the above tasks + dozens more are ignored.
Most projects I know of start with the goal of delivering a quality, maintainable, well-documented product, not just a hacked up product that is impossible to maintain, add features to, and crashes all the time.
The article does hint to the fact that the code delivered from elsewhere is not quality. The article fails to mention how maintainable this code is and if they ever tried to add functionality to the code.
If you develop device driver for example, your're definitely not going to write as many LOC as a VB developer for e.g. (Unless you're Alan Cox that is :-)).
Seriously though it's only applicable to compare LOC output between people doing things that are VERY closely related.
There's sooo much more to programmer productivity than LOC,
pixelbeat...
apprx 5000 lines of perl... granted, prolly 1/3 of the code was just printing lines of html...
(Customer Database interface for a big ISP)
I shudder to think how much code that would have been in VB or some other icky language like that.
Nice poll tho!
The article made no mention of the factors taken into consideration. These things can make a big difference:
* Language - Was the programming language taken into account? Assembly vs. BASIC comes to mind...
* Lines/Hour - Is it better to write more lines/hour or just more lines?
* Definition of Line - What exactly is a line of code? Does it count if you didn't exacly write it yourself (library)?
* Code Re-Use - What if you re-use a lot of your code? Does that count as writing new lines?
* Style - Some people write more elegantly than others, producing less LOC than their competition. Some choose methods that get the same done with the same speed, but less space, etc.
* Efficiency/Design - It is better sometimes to use less code for the same task! Do Americans spend more time actually planning out the program rather than just jumping into the code. Do Americans spend more time trying to find a better way, or do the other countries programmers just go with the first solution they find?
* Responsibilites other than programming. This take a huge amount of work.
IBM had this problem years ago. Their programmers were evaluated on how many thousands of lines of code they put out. This caused problems because programmers were encouraged to bloat their code. I think that if you were to look at how many projects or modules to a project an american programmer completes in a year, you'd have a much different picutre. The best code is usually not the fattest.
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
In my current project, this year I have removed more than 2500 lines of bad code, and replaced it with far fewer and more organized lines.
How does that rate on productivity?
John
You know, I would take the time to construct an intelligent and insightful response to this article, but I am too busy studying to get my CS degree and working on programming projects of my own.
But seriously, even though LOC doesn't mean jack in terms of programmer productivity, people from other countries are going to work harder because it might give them a chance to live in the US. Once they come to the US and become Americanized, they will become "lazy". Why work harder when you can do less and still live at a relatively high standard of living?
Not to mention the fact that laziness is often the stimulus for invention or efficiency. If you don't understand what I mean, try looking up a story from the novel "Time Enough for Love" by Robert A. Heinlein. The story is the one about "The Man who was so Lazy he Couldn't Fail."
Lastly, I would be the first to point out tha patriotism and nationalism are rarely useful and more often destructive (in the long term). We're all programmers/hackers. If we love to program and hack, and we do it well (and not just write more lines of code than other hackers), what difference does it make what country we are from?
Nathan's blog
was better than
Now I have objective proof! My way is 33% more productive!
I once wrote a thousand line program in one day. About the same period in my life, I wrote a 10,000 line program over a period of about three months.
Guess which one was the one-off piece of crap that I hope no one ever sees and which one was the elegant solution of which I am proud to this day?
The trouble with LOC is that it implies that
strcpy(char*cp1,char*cp2)
{
while(*cp1++=*cp2++);
}
is somehow inferior to
strcpy(char*cp1,char*cp2)
{
if( cp2[0] ){
cp1[0] = cp2[0]
if( cp2[1] ){
cp2[1] = cp2[1]
.
.
.
if( cp2[31] ){
cp2[31] = cp1[31];
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
}
Unless you are sure that all your coders are doing the former and not the later, any metrics are not worth much. While obviously this is an exagerated example, I have certainly seen stuff nearly that bad in my career. Hell, I once encountered an API (written by a highly paid consultant) used to wrap a set of ISAM routines whose performance was crap and whose functionality was far more limited than the original routines. I was able to improve performance dramatically simply be removing a five thousand line piece of unnecessary crap.
The frightening thing was that it took me two weeks to figure out that it didn't actually do anything worthwhile. Bad code isn't always obviously bad code.
Until a metric can tell the difference between good code and bad code, they are pretty much worthless, IMO.
Could you clarify what you mean by variable names
...
ambiguous for an ENGLISH speaker? Do you mean
that the names were transliterations of words
in an Indian language? I find that a little difficult to swallow, so you must have meant something else.
Or is it just using short variable names (i,n,num and so on) ? But I don't see how being an English speaker or not affects the readability or ambiguity in this case
Ummm, the reason I found it hard to swallow is
:), just an observation. Of course, I do not have very many data points to go on and you have probably seen more code generated by Indian programmers than I have.
that I am myself an Indian and I know several Indian programmers and have seen code written
by them. Some of these individuals can use English better than their own mother tongue, while it is the other way around for others. In either case, I have yet to see words from Indian languages used as variable or function names. It does not come naturally to some people, they "think" in English when programming. However, this is obviously not the case for everyone.
This is NOT a flame
I guess what I was really objecting to in this
:). It all depends on how well you can use English and whether you "think" in English while programming. My 2 cents.
thread was that being inconsistent or ambiguous in variable naming should not have anything to do with your native tongue. The way you put your last paragraph seems to imply that a native English speaker would understand the value of consistent, concise variable names, while non-native speakers would not. I do not think that is true.
Of course that is a bit simplistic: I'm forgetting that all programming languages use English keywords (except languages like APL that use the Martian alphabet
Well, obviously, remove the word "programmers" from that headline and you have a well known fact. In OO terms, an American Programmer IS_A American, therefore a slacker.
Y'know, I keep seeing a lot of people gripe about type prefixing for variables. I don't get it. Maybe you-all write code in one person shops.
I work with other programmers, and when I am looking through somebody else's code, it's awfully nice to know that:
if (bFoo)
is testing a boolean and not testing whether a pointer is NULL:
if (pBar)
Sure, it gets extreme when you are fully compliant with the convention, but anybody who says that informative variable names are a bad idea is a person who has never maintained or debugged somebody else's code.
I think it's really handy to know that a variable is an instance variable rather than a local (or global).
Sheesh. One letter variable names are for functions that nobody else is ever going to look at (and that the coder won't look at ever again) or for simple loop iteration.
Oh, go on, check out my job.
The purpose of the H1B visa program is to get people into the US with rare and/or specialist skills. NOT cheap labour.
In order to get a H1B visa, your employer needs to be able to prove they are unable to locate a US peep who can do the same job.
It is far cheaper for a company to open up coding departments in countries like india where they can find several hundred good programmers at a time than going to the time and trouble of shipping them over to the US.
Getting a H1B visa is not easy - if I remeber rightly (and I may be completely wrong and if I am someone corect me) rasterman had problems getting in on a H1B visa.
noidd
While this was my first reaction (shorter is better), here's a counterexample:
Almost any function can be written in one line of perl. That line will probably resemble line noise.
Is it better than a neat, 20 line function? It may show mastery of the language, and it may impress your fellow geeks, but it won't impress the person who has to figure it out 2 years later at 4am.
I've rewritten code before, with a good 20:1 expansion ratio, because the original code was too clever for its own good. I've even rewritten my own code before, when I realized that nobody else (at least, nobody sane) was ever going to be able to figure out how or why I wrote something the way I did, even when the original, shorter way was more 'elegant'.
Forward, retransmit, or republish anything I say here. Just don't misquote me.
That totally accounts for the difference!! Typical 80 column code uses 1/2 the # of lines :)
How do you guys do your commenting btw.. i've taken to putting comments on the 90th+ col. or so.. that way I dont normally have to look at it
(it totally breaks up the continuity of the code by putting it above and below the code *imho*)
But still it is a simple shift over to read what ever snappy comments i've come up w/ woohoo!
When I write code, I write it for the sheer pleasure of coding as I am sure most of you do. People like me tend toward programming techniques that industry would avoid, because they make difficult reading, recursion etc.
I apply the rule my old maths teacher used to say "Mathematicians(Programmers) are lazy" and its not neccessarily a bad thing.
However when you look at industry, that is where you can make a better comparison as code is written to be able to be read at some stage in the future and therefore bad programming practises are avoided, and code tends to more iterative.
If American Industry programmers are called lazy, I would say good luck to them, 'cos they are getting away with something I can't (C:
Regards Redemption
I have another lines of code which seems indicative of this totally bogues thinking. The group I work in was hired to work on some networking code (Telephony stuff) when we came in we inherited piles and piles of code. A lot of this came from the days when the raises were based upon lines of code checked in. There was crazy code bloat. One particular piece of code had a massive switch statement where most of the cases were duplicates, instead of just falling through into a single case the programmer had cut and pasted (every decent programmers enemy) the same piece of code into each case. I practically cried when I saw the code (I thought I was walking into a job with great engineers where I would be learning from my betters - what do you know it's a farm for cubicle monkeys seeking to develop bigger bottoms).
I must agree with the sentiment that if you're putting out tons of code every day it's probably crap and it's most definitely not going to be well organized. Code less, think more.
gid-fu
Everyone knows that "lines of code" in the sense of the output from "wc -l" is totally useless as a measure of anything. That's just a strawman. Most "lines of code" measures at least take some account of braces and comments (though there's debate about whether it's fair to exclude comments) and some even take account of statement complexity to yield a _somewhat_ useful measure of productivity. But even finding fault with that is little better than attacking a strawman, because anyone with an ounce of sense knows that _any_ measure based solely on the code itself is likely to be inaccurate.
Any idiot can write 20K lines of code a year. It gets harder if you're only counting _properly debugged_ lines of code. It gets harder if you have to design whatever it is you're coding, and document the design, and have code reviewed, etc. It gets harder when what you're writing is intrinsically hard, such as a compiler or OS instead of GUI eye-candy. If the standards for non-coding activities are not held constant, the coding numbers are meaningless, and you can never really compare different types of code. I've worked with some people regarded as superstars within the industry, and very few of them can sustain a coding rate of even 50 lines of well-written, well-debugged, designed-from-scratch and reviewed kernel code per day. That's only 12.5K lines per year, but worth far more than 25K lines of derivative user-level crap any day.
Now the irony part. From the article:
>One alternative is to tap reusable software components and object technologies to improve software development productivity
Think about it. Reusable code does improve _real_ productivity but by definition does not contribute to one's LOC numbers. It would be entirely reasonable to suppose that part of the reasons for US programmers' low numbers might be precisely because they _do_ take advantage of code reuse. Padding LOC numbers by writing a new version of something that already existed, because you didn't know any better, is a failing typical of very junior software engineers; more experienced hands know better.
For the authors of this article to criticize US programmers' "lack of productivity" using LOC, and then suggest code reuse as a solution, only shows their own ignorance.
Slashdot - News for Herds. Stuff that Splatters.
C, C++, Java, assembly, and CSH at work.
Last project was a 15KLOC Java app (around 90 classes).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I totally agree. Likewise the embedded world can be almost as bad (in some cases worse depending on the environment).
I had a lot of fun working on an OS/2 ATM device driver that was around 100KLOC lines of code. It was a dream compared to the 360KLOC NT equivelent driver written in C.
Then came NT 5... Can you say spending a week just trying to get the driver to install after Microsoft released a new beta that broke the install script (which MS wrote to begin with) and WinDBG crashing EVERY FIVE MINUTES LIKE CLOCKWORK?!?!? Then there was the constant crashing MS kept complaining about which was traced down to the fact that MS wasn't updating the registry (which we couldn't duplicate since they wouldn't send us their latest build). I spent 3x as much time just fighting stupid MS issues instead of working on the code.
Dealing with user space is much easier.
After dealing with WinDBG you don't know how privileged you are with GDB.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
My definition of a line of code:
;)
import java.io.*;
from the first word in the command to the ending punctuation (in Java/C/C++, the
Slackers? I would love to see a Frenchman try to do what I do on a daily basis.
RB
I'm sorry but I fail to see how a monstrosity such as visual basic could be important whatsoever.
:P ]) and native code compilation the language is now a lot closer to C++ than most people realise.
A lot of commercial development is done in VB5 and VB6 because you can build apps (particularly DB-based stuff) pretty quickly. VB prior to version 5 really did suck, but with the new OO features (sans true inheritance [they have a hacked implementation
VB also lends itself well to prototyping, a common commercial approach to software engineering these days.
Cheers,
Alastair
-- "I believe the human being and the fish can coexist peacefully." - George W. Bush, 29 September 2000
I wound have to disagree with that one.
;;;;;;;;;;
void main()
{
}
This is NOT a 10 line program.
That is awfully steriotypical.
Not all forgeign countries are like that.
Seems that MS should be looking really good in this poll.
Bloatware = Productivity... I don't think so!!!
"How much truth can advertising buy?" - iNsuRge - AK47
When Carlos writes a paper, he can only sneeze 500 words. But when Carlos writes a code, he can sneeze 1000 lines?
*Carlos: Exit Stage Right*
"Geeks, Where would you be without them?"
"Got Linux?"
For C/C++ merely count the semicolons. This eliminates '{' on current or next line style differences, as well as put every function parameter on a separate line type of differences.
Oxryly
Strange... you would think US programmers had the world record in LOC because of Microsoft :)
:)
LOC is a tool made for thoose who manage programmers, people who knows next to nothing about programming. Therefore they need a tool to mesure the progress and effictiveness of the programmers they are managing.
What they don't realize is the fact that the low LOC often isn't because the programmers are lazy or of poor skill, but because they just don't know what to code because of very poor management.
Or it all might be because programmers don't want to be slaves anymore, there IS more to life than computers.
The worst code I've ever seen was written by a guy who wrote a lot of it. He also went on to become a well-respected manager, nuff said. Some of the best code I've ever seen e.g. the Python source, has exactly the right number, no more, no less. My personal goal is to approach 0 LOC, which seems to be happening as I find I can get more real work done using only scripting languages these days.
BTW, despite the fact that a lot of the best programmers in the history of computer science were electrical engineers first, why is it tha invariably the ones I come across in the real world are incapable of writing elegant or even passable code? Just wondering.
Raw lines of code doesn't take into account many factors, including code/architecture design, domain engineering, incorporation of COTS products, customer briefings, design reviews, code/unit test, system test support. It may give an idea of the system complexity or the system inefficiency, do they really know. I heard all kinds of managers talk about SLOC, I say SLOC off.
It's stupid to think that LOCs anything to do with productivity. In programming, it's the person who can figure out the problem and how to implement it most quickly and easily who is to be praised, not the one who writes the most code. When it's time to maintain that code, which would you prefer, clear code (long | short) | convoluted code (long | short). Which brings up another point that this does not take into account maintainance of code.
IMO, part of the problem in measuring sucess by LOC is that the vast majority of my work is maint coding. I just move the same LOC around. One of the "new" programs I wrote within the last year was a conversion of an existing program from one language into another (actually 2 others). So my net LOC was lower than the work entailed would indicate.
available for the code I write... nothing but the basic Intel Pentium registers. I guarantee you my productivity sucks by a LOC measure, but there's damn few people that can do it at all...
--Rob
BIOS developer
--Rob
If LOC is deciding factor in the proformance of software than Windows 2000 is god. With over 2 million lines of crap it's the King of LOC
Basing productivity on lines-of-code is
like driving from LA to Boston, by way of Mexico
City an efficient trip. Remember, it is not the trip, but rather the destination.
I personally believe that a lazy programmer == a good designer == a great programmer. Being lazy
forces one to use Occam's Razor and one's mind to cut out the dreck and inefficiencies.
Things are worked out in my head and notebooks before they EVER see a keyboard. And less lines og code result with more elegance, reliability, reusability and maintainablity.
Brevity is the soul of wit *and* programming!
An exellent choice. It is often said that Leo was paid by the word for that one. I'll insist on being payed by loc if I ever get a job.
No, his ACCOUNT is Swedish. At least on the first leg of the journey. Then an anonymous forwarding service sends it by way of New Zealand, Zimbabwe, Japan, Chile, and finally to his REAL home in the Antarctic (after all, isn't that where penguins come from?)
:^)
I agree with some of the other comments made about this article. Lines of code is a very ambigeous way to measure productivity; however, it is frequently used by Lazy, ignorant (they don't know about programming) managers. Lines of code -- in what language? Assembly language, COBOL, C, C++, JAVA, PL/1, PASCAL, SQL, PERL, HTML??? Are comments "lines of code"? How do managers / consultants measure the time to properly design a project? Design time of a large commercial project is often 60% to 80% of the total time spent developing a system - and yet not one line of code is written during the design time. Is good design work "unproductive"??? It is difficult to impossible to write good code without knowing in nit-picking detail what you are going to do.
P.S. I once wrote a little over 1800 lines of PL/6 (a pl/1 like language) for gathering internal statistics for a relational database navagator in just under a month. Do the math! But I also had a through knowledge of what I was doing.
No, it's me!!!
You are right, It takes a lot of work to make the code as simple as it can be. Fewer LOC indicates more tought put into the project.
If you interpret the conclusion that Americans produce less ocde, i.e they must be lazy. Then you should be able to say the inverse about MS based on the amount of code they produce or do not. But we all know it would be a dangerouse assumption becouse what I beleve are these two rules: #1. the code defines the application #2. well thought out code produces a well thought out application. (lazy?) And one might infere a third rule: #3. massive code could easily produce massive applications. So when i take all this info in I can only come to one conclusion. MS may not be well thought out but they are not lazy. I think I would have more pride in being lazy.
Thats the name i call out when i need some coding done :P
I use Common Lisp for most of my projects.
See why at http://www.goems.com/~sds/tool.html
Gosh - it's Decline and Fall of the American Programmer - 1999. After programming more than 20 years, 15 as an independant, working on projects around the globe, I'm here to tell you that this is hogwash. Annoy my global friends this may, but we have the best here. Ever hear of the brain drain? Anybody good any place else on Terra makes their way to the good old USA - better access to the latest technology, the Net, Mountain Dew, - and, most importantly, the best rates for us mercenary contract programmers. And while an MS from a foreign U may look impressive on paper, it may not have been earned studying the latest. And that's assuming what's taught in college is worth a damn out in the real world - a subject for a whole 'nother poll. And the criteria for this - Sorry CNN - your metrics bite the big one. Here's an example - one newbie at a clients' site recently wrote a COBOL program of 25,000 lines. Turned out to be a pig performance-wise. I rewrote it in C in 2,000. But according to this metric, I'm inefficient and lazy. Sure - can you say "code bloat" anyone?