OSDev.org

I can code a lot of code per hour, but it will have several bugs in it.
Plus, when I finish writing a huge function I'll stare at the screen for minutes until I compile it looking for obvious mistakes.

If it's simple system functions, I can code much per hour with few bugs. If it's complex, there will be more bugs, and I'll manage less per hour.
Thats pretty simple, and I think universal.

-JL

@quok: Respect!

Sorry that all makes me feel sad... why don't people read at least some few papers about "LOC" and the whole problem behind it? I bet 1/2 h googling for this would excavate a nice collection of texts. Plese go and try to read some of them.

There is the need of getting a useful answer to such Questions like:
"Who is our "best" codemonkey?"
"Am I performing adequately?"
"Whom of the monkeys should we get rid off first?"

or like:
"How can we increase productivity, (or quality)?"
"Show me the levers where I can tune workflow"
"We need the BEST developers, how can we attract them?"
"We need to cut costs, what will we do and what will be the effect?"

It is SO annoying, that still nowadays, after all the case studies and scientific investigations, still some people are thinking in terms of "lines of code per timeunit". Must be something hard-wired into human brains? The need for a simple "compare-function"? That works great for integers and that fails already for strings (Compare "book" "cook" "literature" "blog" "log" - What is "the" (TM) distance of that strings? Wich string/word is (lexically, vocally, semantically?) most similar to word "book"? )

People thinking in LOC or suchlike are definitely (scientifically approved!) asking wrong questions. They try to over-reduce complexity, because they have too little experience with the problem domain of software development, which is itself an intrinsically complex and creative one, where problems of technique and humans tightly interact. The domain consists of many orthogonal sub-domains. To keep in budget is constant pain and even "only" staying on timeline is often burden. Then the "quality" and "quantity" of projects, etc etc... Oh - and then some people still try to "rate" codemonkeys with LOC? Stupid!

Ah - one thing: all studies have one common (and funny) result: People demanding for this kinda measures do recieve codemonkeys that are optimizing for that kinda measure. So if one wants to measure e.g. "LOC - without comments", he recieves but utterly unreadable write-only code, aannd much of it.
People were surprisingly inventive creating more and more complex "measures" - e.g. IBM was leader of this bullshit in the 1960-1980. Find a formula for "good, readable, stable, maintainable, but also plenty, and in little time etc... code". The effect was: They "educated" their developers to optimize their behavior to exact that thing. And that was simply not what helped the companies. Nowadays (I thought) people tend to accept that software development is not optimizing a formula. Maybe parts of the workflow can be delegated to codemonkeys, and other parts to more experienced developers / architects / whatever. But still it won't fit into plain formulas.

O.K. I' ll give my story, and why it comes:
In early days I thought to myself "O.K. you took just three hours to code this piece of 500 lines! Great time! But after another 3h I realized that I were just exactly where I was - just few lines more. Frustrated, but I continued to selfmonitor. And after three days I had my piece "done". Result was ~700 LOC, now including much more comments. (Testcases - I didn't know of in these days)
But the whole truth was, that I was planning on that subject some time before, and there were lots of bugs, that I fixed bit by bit (introducing some new bugs, to be fixed, too!) After that self-monitoring experiment I admitted, that I simply cannot estimate a project by LOC or even codesize. Not at all. (Of course codesize IS a rough estimate of the problem size).

Try it yourself - self moniter yourself now and then. You'll be surprised HOW MUCH TIME YOU "WASTE". Punktually you surely are extremely productive, but on the large scale? Inspecting the problem, developing ideas, learning the proper technique (Newbee in that language? New library API to get into? Unknown Tool?) all takes it's time.

My OS FAT driver is over 1,500 lines of code and I wrote all of that in around 2 hours. It worked straight out of the box with only one bug, which was related to my driver interface anyway.

Sometimes though, like when I implemented TCP, I would've been lucky to write a hundred lines of code in 2 hours.

It really depends on how complicated the spec for whatever I'm programming is, how much time I have, and (most importantly) the music I'm listening to .

I see people saying that lines of code per hour is irrelevant. I don't think it is. In fact, I think it's very relevant. However, it should be lines of code removed per hour, not lines of code written.

The number one goal should be clarity and then performance-through-simplicity (no slow unneccessary layers) (1). To achieve this you need to remove code (but not at the expense of clarity and functionality - this is the challenge).

Removed code is debugged code and doesn't use any memory or CPU time. Well done if you didn't write it, even better if you can remove it!

(1) Only after that should further performance optimization be done.

If you're really good, you can actually get a negative result for 'number of lines per hour'.

I refer you to this great story from http://www.folklore.org


In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.

Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.

He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.

He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.

I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.

Eddy

Craze Frog wrote:I see people saying that lines of code per hour is irrelevant. I don't think it is. In fact, I think it's very relevant. However, it should be lines of code removed per hour, not lines of code written.

The number one goal should be clarity and then performance-through-simplicity (no slow unneccessary layers) (1). To achieve this you need to remove code (but not at the expense of clarity and functionality - this is the challenge).

Removed code is debugged code and doesn't use any memory or CPU time. Well done if you didn't write it, even better if you can remove it!

(1) Only after that should further performance optimization be done.

Lines of code by itself, whether written or removed, is totally irrelevant. You can write or remove hundreds of lines of code a day.. Hell, rm -rf /my/project/tree/ would remove lots of code, and similarly copying the linux kernel sources into the project tree a few times would create even more code. My old boss would have been so damned proud of me if I had thought of that back then.

Really though, lines of code alone is just open for abuse no matter which way you put it. It puts no emphasis on design, performance, clarity, maintainability, documentation, testing, etc. A really good metric would track all of those.

For those of us that quit our jobs that day, we did so because the boss-man refused to see that anything else mattered. We had been fighting that with him for a very long time, and software quality was very poor. Morale was quite poor as well. Imagine how you'd feel if you spent 6 months doing nothing other than fixing incredibly stupid bugs introduced by someone else and then got punished for it. The "bigger is better" mentality of the boss-man went against what the customers were looking for as well, especially since in this case bigger meant more bugs. Since nothing but lines of code written was being tracked by management and used for reviews (despite us actually having many other metrics, including avg # of bugs / x lines of code, # of bugs fixed by y, introduced by z, performance gains and losses of rewritten code, etc). Those of us that cared had the lowest # of lines of code written (although perhaps the highest lines of code removed), but we also spent a lot of time doing the things that supposedly didn't matter like writing documentation, optimizing, and testing our code.

The company was losing customers because of the sinking quality of the product. The boss-man/owner of the company didn't care, he took the attitude of "we don't need that customer" constantly. In a very niche market like we served, every customer counts. Amazingly that company is still in business. From what I hear, lines of code written is still the only metric being used for developer's performance reviews (well, aside from attendance), and the software quality is still horrible. Apparently the company is adding customers just as fast as they are losing customers. Their total customer count is roughly the same as it was when I left.

I will admit a lot of the problems faced at that company were because the boss-man didn't have good business sense, let alone development sense (despite him also claiming to be a developer). However I think my point of lines of code itself being bad still stands and is pretty well illustrated here.

I agree that lines of code is irrelevant. Better is a properly constructed requirements document with clearly defined interim objectives.

Make a list of things you need to get working correctly. Break these thins down into smaller sub-tasks which have some form of meaningful scope in themselves. Check them off as you've done them. Maybe have an interim test case outlined for each one which you need to satisfy before you check it off.

Measure your progress against these things, not the amount of code it does or doesn't take to achieve them. Of course you need to have further test cases to QA the result of completing multiple steps as well.

Eddy

PS: I still love the -2000 lines of code story tho

I never actually thought about it. Clearly it depends and is also irrelevant. But out of curriosity, I will check. I wonder how many LoC/h Brendan does. Did any of you guys notice all his posts on the forum are huge?

Hi,

Love4Boobies wrote:I never actually thought about it. Clearly it depends and is also irrelevant. But out of curriosity, I will check. I wonder how many LoC/h Brendan does. Did any of you guys notice all his posts on the forum are huge?

I can type fast, and probably reach speeds of around 80 words per minute fairly often (e.g. when posting on forums).

Fast typing doesn't translate into fast programming though. If I'm writing simple/easy code I get bored and start thinking about other things, downloading stuff, checking the forum, etc. If I'm writing complex code I spend a lot of time thinking about what I'm doing and not much time actually writing the code. Also, on average I probably spend as much time writing documentation as I do writing the code itself.

"LoC" is also a very dodgy measurement. For example, lately I've been re-writing my floppy boot loader and my PXE boot loader, where half the code is cut & paste from the previous versions, and most of the code is the same for both boot loaders (write/modify the code once and copy it "as is" to the other boot loader). This is unnaturally fast "LoC", until I reach a certain point...

For an example, my previous boot loaders used "int 0x10, ah = 0x1C" to determine if a VGA or better video card is present (and decided the computer is headless if there wasn't). While testing I found that all VIA systems fail (the ROM for VIA's onboard video doesn't support this function for some reason, so my OS decided they're headless when they aren't), so I spent about an hour trying to find an alternative that works on all my test computers, and then spent more time wondering why I care if it's VGA or better during early boot, and then decided to check if "int 0x10, ax = 0x1A00" exists (without caring about returned values) and let later code worry about if the video card is good enough. In this case I probably did about 6 lines of code in 2 hours (not including code I wrote for testing and then deleted)...


Cheers,

Brendan

I type pretty fast too. What I meant by my previous post is that if you like typing code as much as you like typing on the forum, it's probably going to be a lot anyway