|
I Can write 100 lines in just 4 or 5 hour or 4 lines in
one week! But the day I wrote 100 lines I sure did wrote them!
I think this mesurement is Crap! Its for pencil pushers and ppl in stupid marketing positions that want some kind of new way to mesure effiency of nothing!
Its only statistics and lies and more lies!
IMHO xandx
|
|
|
|
|
As a part-time pencil pusher myself I take great umbrage at your remarks.
Actually, I don't know anyone who uses LOC as a club to beat on developers for their lack of productivity. Most people I know who throw around this number do it to try and help in the estimation of time and costs for new projects.
Estimates by nature must deal with risk and uncertainty, and while LOC is useless as an estimation metric unless skillfully applied, what else do we out there.
Like I said, I'm looking at function points as a substitute for LOC as a usefull metric to use in estimating.
But I don't think LOC is necessarily totally useless.
Lori
|
|
|
|
|
I'm wondering what exactly this survey is measuring. Code produced when you've actually reached the phase of the project where you write code, or the average over the whole project.
On a well managed project, the actual writing of the code should be an afterthought done in the last 20% of the project. Gathering requirements, designing the architecture, doing high level and detailed technical designs - all this preceeds the coding phase, and if done properly, the code should just about write itself.
Later, during testing and debugging, there will of course be some additional coding done, but again, the number of lines of code is irrelevant there. A good design ahead of time will likely reduce the number of lines of code overall.
Now, if you are in a bad organization, (code-fix) then you code all the time, but that is just not a situation you want to be in. There you can produce tons of code and look really productive, but all you are doing is running around in circles.
In my movie imagination, the programmer comes in on a white horse, after having spent three months designing the system, dismounts in a leap onto his or her chair, spins around to stop in front of the computer screen, types in the code based on the impecible design, compiles and runs it - and thus the coding phase is over and testing begins.
Ya'll come back now, ya hear
|
|
|
|
|
I don't think it is meaningless, but maybe it doesn't tell the whole story. We need some metrics to measure not only productivity but also to help in future project estimation.
Take the number of lines of code delivered and divide by the number of developer days. Of course it is probably a more meaningful metric when you have a bunch of projects, some in design, some in implementation,a nd some in testing... but it is kind of an interesting metric.
We are fooling around with the idea of using function point analysis in our estimation process.
Anyone here using function point analysis?
Lor
|
|
|
|
|
Having a defined standard metrics for your organization may be an effective way of understanding your coding skills, if used correctly.
Using the proper statistical tools, by feeding lines of code into the proper formula, can provide insight where your developers need to focus more on design before starting coding.
When that is said, you cannot compare LOC without defining LOC. While one organization counts physical lines, another one counts only reserved words ..
|
|
|
|
|
Lori,
An organization I was in previously did use function point analysis, and in my opinion it is FAR better than LOC analysis.
The thing is though: what it measures is the complexity of the code. A really well designed app should be less complex overall than otherwise, so the numbers can be misleading, and should not be taken at face value
|
|
|
|
|
A collegue of mine had a negative figure, because he spent all his time deleting the crap I wrote!
Kind regards,
Al.
VBer who wants to go back to, but will have to learn again, C++. I'll carry on using VB for the front-end; so when I get proficient at C++/STL can I jump straight to ATL and avoid the MFC
|
|
|
|
|
Very good point !!!!! and it also depends on the stage of the project you are in.
At our establishment we do a lot of work with generating code directly from a specification that is in the form of an access database. When code generation is run it can generated a few 1000 lines of code in a few minutes. Do I add that to my count? if not there are days where I do none at all then.
We also use SDT which is a Tool for inputting graphical information that is turned into C/C++ code. In this case we never even look at the code let alone count the lines because the final code is for an embedded system and has to mean and lean.
Regards
|
|
|
|
|
How can you write 251+ lines of code? Copy and paste or what
|
|
|
|
|
|
Its easy. Work for youself. Meet deadlines. Write real world code instead of scholastic demonsration code.
Heck. I have had days when I wrote over 1000 lines of debugged commented code. Do I spend my time writing
custom controls - No. Do I spend a lot of time writing my own sort routines - NO. I do however write the
code to do the necessary task as well I as I can. Could it be better? Yes. But that leads one right back to
the mighty software trilogy: You can have it FAST, CHEAP,or GOOD. Pick any two at the expense of the other.
I could go on but why bother. If all you can do is < 250 lines of code per day than better find a company
like MS or IBM and stick there. Them good ole team managers will tell you what and how to do it.
|
|
|
|
|
Easy? Hmmmm....
First of all. The lines of code figure does not include comments, blank lines, or other non-executing code. I suspect this may reduce your figure somewhat.
Second. And most important. Take your code, count all of the executable lines in it, and divide it by the number of days the project takes. This is important, the number of days is from the time you start, NOT THE TIME YOU START CODING. The finish is the day the project is delivered, or if it is a personal project, the day you are happy all the bugs are out of it.
Count a day as 8 hours, so if you spend two four hour days on a project, that is one man-day.
Oh, and thats for one developer. Don't forget to take into account multiple developers on a team.
If you run these calculations, I'm pretty positive there will be very, very few with results of more than ten or so lines a day.
Actually, I suspect MS figures are about average for the industry. A little lower than I thought. The numbers have been around eight lines a day for about 15 years now. Or so I thought. 
regards
Joh
|
|
|
|
|
Whaaat? In an 8 hour day, that's 1 line every 30 seconds. All day. Non stop. When do you have time to think? You must be exhausted :-
|
|
|
|
|
surely you mean it is 1 line every 2 minutes  You must have been working too hard ;
|
|
|
|
|
Nooooo! Richard's thousand lines in a day, would be 1 every 30 seconds. As it turns out, his day is somewhat longer :-
|
|
|
|
|
There are a lot of developers at MS where there searching out bugs, and fixing them, so its possible that the average is that... but that would mean that there are a few who are writing a whole lot more... a whole lot more.
How much email do you type vs how much code you type?
If I'm building something new, and I have a good understanding of what I need to do, then easily a thousand lines of code will come out. Finished. Commented. And commited. Not unit tested, code reviewed and bug free though.
heh
|
|
|
|
|
That was an even better answer.
It doesn't happen frequently any more, but I have at times been inspired enough about a project to produce amazing amounts of output -- 2500 lines or more of C/C++. In one instance I completed just under 4000 lines in one sitting (15 hours). Commented, working code. No, it wasn't perfect, but it met the immediate requirements, and was easily maintained afterward.
These days, my average isn't nearly so high, given the sponge-like properties of meetings, paperwork, mentoring, design work and so on; my average is down around 30 to 60 lines, if that. (Designers don't get much time actually writing code do they)?
But if you are a full-time coder, and completely understand both the software requirements and the environment within which you're working: 250 lines is not that steep a target.
|
|
|
|
|
|
Think once and the code will follow naturally. Creating a window takes two lines (if you are using a normal font and you want to see what you are writing on the screen...), and the window procedure have also a declaration, an implementation with a switch, default, break, the return DefWindowProc, the brackets so, for a Window procedure which does nothing that call the default, it's
LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg)
{
default:
break;
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
and we have already 10 lines. Agree
|
|
|
|
|
I write 10,000 lines of code a day or do I sniff 10,000 lines of coke a day, I just can't remember. If I add in standard header files do those add to my count? I think that's how Richard counts.
|
|
|
|
|
No I leave the dope to dopes. Take a simple lookup table consisiting of N0 - Nx rows and C0 - Cx
columns of numbers to be searched based on critera where Input == N(0) and output is Col(x) where
x is the current time in hours (0-23). Bounds is Nx > -1 && Nx < 100 and Cx > -1 && < 24. If I am
writing the amount of code that you fine people are I will spend about a week or so just doing this
simple lookup. If I work for Mega Corps maybe they won't notice or care and I can justify this by
pointing out that Nobody else is doing any better. However I work for myself. I tell my customers
that it will take six weeks and $12000.00 to do the project. This is a trivial amount of code compared
to the whole project.I can't afford to produce empirically correct code with copious comments and lines
and arrows on the back pointing out gems of interest and wonderment. I write the damn loop and move
on. I do use canned procedures and libraries whenever possible but even leaving the GUI code out of
the mix and not counting ANY MFC code at all I stll heve to write 300-400 lines of just processing code
a day to make much of a profit. Most of you probably don't do any processing at 20 -30 lines of code
a day. I write ALL my own printing code, processing code, input-output verification code, error handling
code, and file IO on an indiviual basis. No MFC, No report writer, no CRecordset database stuff ( I have to
write fairly portable code on the back end to port to Unix ).
Richard
|
|
|
|
|
I once wrote over 150,000 lines in a day, no comments, but bug free. How did I do it? I wrote a program that writes program code.
You have to be smarter than the tools you use
|
|
|
|
|
Yeah 251 a day would be hard, especially near the end of a project
|
|
|
|
|
Once and only once I did achieve an average of over 3000 executable lines per day in a single project. I spent about 16-18 hours per day for about 12 days straight, with no breaks except for sleeping and maybe a snack or two. At that time I was coding in a mix of Turbo Pascal and assembler and produced a completely functional application which required no debugging and contained no in file comments whatsoever. The finished app was over 40,000 lines of code not counting libraries or re-used code modules.
The pace was insane, and I slept for two days before I delivered the product to the customer... does that count? I also lost about 20 pounds...
|
|
|
|
|
Have you ever tried ASM
or Pure Basic from scratch!
LOL
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
