It's Not About Lines of Code 517
Charles Connell writes: "What makes a programmer highly productive? Is it lines of code per
day? Lines of good code? In this article, I examine the concept of software
productivity. I look at some of the standard definitions for productivity
and show why they are wrong. I then propose a new definition that captures
what programming really is about." Read on for Connell's stab at a better way of evaluating the worth of programmer time.
CT Originally the contents of an article were here but there was
a communication problem resulting in us thinking we were given permission to
print the article here. Now that things have been cleared up, we've linked
the
original article which you can read instead.
Sorry about the inconvenience.
Classical measures of productivity (Score:5, Insightful)
Re:Classical measures of productivity (Score:5, Insightful)
Re:Classical measures of productivity (Score:5, Interesting)
Re:Classical measures of productivity (Score:3, Informative)
That would depend on the development method and the actual product being developed. If you're developing APIs or libraries for other people to use, then you really can't "see" how far along it is, although you could count function or components complete. However, if you're developing something like a website or a client application, then you can see how far along things are though.
Of course I completely agree with measuring lines of code being boneheaded, unless of course the number of lines of code for the final product is known before it starts. Luckily I work with people that understand that numbers are irrelevant, and that the product won't be finished until long after it has been released to the public.
As far as an ideal solution, give the managers the convoluted formula of computing productivity that results in an answer that only slightly deviates from a standard amount. That way at least they'll stay out of your hair long enough to get some coding done.
Re:Classical measures of productivity (Score:3, Interesting)
"Percieved" progress and "actual" progress can vary. A prototype can give a lot of percieved progress but no (hopefully) actual progress.
80-20 rule always kicks in when trying to measure progress. I've known developers who manage to keep their project 90% complete (yeah, you know who you are) for a very long time.
I prefer having an almost constantly shippable product from the outset. It's difficult to achieve early on but it can be done very soon with basic functionality.
It also provides a good way to test design and implementation. Aim to get something working within spec. asap and everyone will be pleased.
It also provides a good measure of progress. Ticking features off a list reassures the managers and gives a good boost to the team. Admittedly it's not possible for some projects with lots of core features needed to be built from scratch.
Should the shit hit the fan (like a competitor doing a release) then features can be dropped and the product shipped much quicker. It means renaging on some promises made to customers but if you have been open and honest with them they'll understand, also, if you release early/often they don't mind waiting for X if the have Y.
You've just got to keep an eye on the team, harass them for quality, and reward excellence.
My measure of productivity is based on delivery of code/features that falls within my quality guidelines. This includes lack of bugs, code layout, comments and reuse. e.g. A feature can be 'working to spec.' but if it has no comments in the code then it's not 'finished'.
I also know developers that quickly write the code, do all the testing and then call the feature finished. They then go back and add comments, correct variable naming and touch the code in other ways (adding whitespace, reoganising if's) - they fail to realise that they now need to perform all the same tests again, which of course they never do. This is *low* productivity IMO and is generally poor style.
Coding *is* art and I am an 'artished'.
Re:Classical measures of productivity (Score:4, Funny)
This is why the iterative development method is useful -- you set a certain number of things you want to see done by such-and-such a date (best done with the interaction of the developer), then if it's not done the developer better have a good reason.
This approach works on most development projects (with the possible exception of very new projects with no existing product) and only when at least the lower level managers understand the development of the project and can participate in setting the goals.
Oh, and here's the big secret: then you build on an extra 15 days for every six months of the project and don't tell anyone involved with the development. That way, you look like a hero if it gets done in time and don't lose your job if its not. Don't tell anyone.
Re:Classical measures of productivity (Score:2)
Re:Classical measures of productivity (Score:2)
No! Creatitivity can not be compelled. The parent post spoke of Michelangelo, so you should do some research before replying. Read The Agony and the Ecstacy for a better--although fictionalized--insight into the life of an artist.
Re:Classical measures of productivity (Score:4, Funny)
"I need you to be great and create something totally fantastic and immensely profitable by Friday, Can you do it?"
Why programmers consider murder:
"What's taking you so long? I've already built something just like it in Access."
Why programmers retire early:
"We're totally bankrupt, you probably didn't work hard enough. Thank goodness I've got a golden parachute."
Re:Classical measures of productivity (Score:5, Insightful)
Memo: Design Revisions
We want corporate statue to have the head of a St Bernard and the torso of a gopher. Can you throw in a couple of extra arms while your at? 4 or 5 should be enough. Need to move the schedule up while we're at, investors will be visiting in two weeks and we need something to show them.
Thanks,
Management
Tony Hoare (Score:3, Insightful)
I don't think anyone has ever claimed lines of code per day is a useful or meaningful measure, except of course for pointy haired bosses.
Re:Classical measures of productivity (Score:5, Insightful)
What this has to do with software is sometimes the customer doesn't know what they want. Sometimes management has to trust the artist. And sometimes the amount of work is less important than the quality of work.
Re:Classical measures of productivity (Score:3, Interesting)
To create a tool for use with art (say a paint brush) in itself is a craft, but to make a beautiful styled handmade 'one of a kind paint brush' with your skills certianly takes you out of the relm of just a simple craftsman. I would think that photoshop is the 'one of a kind brush' and 'paint' is norm in the craft.
could this be possibly be more useless? (Score:5, Insightful)
Re:could this be possibly be more useless? (Score:3, Interesting)
This is old news, and if a manager is looking at lines of code produced, as opposed to general quality of the overall product, your manager is 95.
I have yet to see a manager look at "lines of code" as any type of measurement.
Has anyone?
I have! (Score:5, Insightful)
So then he asks "how many lines of code do you have?" I tell him that I don't use that as a gauge, I use what I just told him for my progress. Also told him that I don't count lines. He persisted, so I came up with a rough count. He says "so if you say you're at 60%, and have X lines of code written, then you'll have Y lines when you're done, right?"
I had to reiterate (for the third time in that phone call) that LOC means nothing - it may very well be that I only had 100 lines left to put together, but it would tie up the remaining functionality needed (by gluing all my pieces together).
But he just kept coming back and harping on that LOC number, no matter how I tried to persuade him that it was meaningless. He was convinced that this was how he would know how much work went into the project. I guess the 3 weeks of writing very little code and charting out the logic of the app didn't mean much to him. He was taken aback when I told him "I don't just start writing code on day 1, I plan things out"
Re:I have! (Score:5, Funny)
Of course, you still need to finish everything on time or your arbitrary and meaningless answers won't work the next time.
Re:I have! (Score:5, Insightful)
The project manager called me one day out of nowhere to ask where my progress was... I started giving him percentage estimates based on feature completeness, structure completeness, etc.
So then he asks "how many lines of code do you have?"
You should of told him that just today you Enhanced Shareholder Value by rearranging your equations, converting this:
Foo
to this:
Foo
Foo
Foo
This lead to a threefold increase in lines of code, whilst making the program clearer and easier to maintain.
Tomorrow, you should say, I plan to modify all our string-processing code to work only in the flexible and intuitive EBCDIC instead of the ASCII which we already have libraries for. Liberal use of copy and paste could lead to a 65% increase in lines of code.
Michael
Not LOC, but HIO (Score:3, Informative)
However, I still lots of people's effor being measured by HIO (Hours in Office).
Re:could this be possibly be more useless? (Score:3, Insightful)
Having said that, the fact that he offers no alternatives does make the value of the article questionable. But perhaps the point of the article was to raise ideas of how one could evaluate the amount of work done - and the author didn't want to bias this by suggesting a particular method?
If so, then this is far preferable than an 'Ask Slashdot - how do I measure my programmer's productivity?'
Re:could this be possibly be more useless? (Score:5, Insightful)
It is from constant retelling of an idea that the idea becomes accepted into culture and things begin to change.
This is a good idea, so help spread the love man.
-AP
Re:could this be possibly be more useless? (Score:2)
Uh, it looks like this blurb was introduced as an item of discussion and not a research paper. I thought the blurb was cleaning written and succinct about an issue of interest to many
Economists generally define productivity as the amount of money that your product brings in compared to the hours you worked on it. In this case, the MS programmer who dropped a nasty bug in WinWord, and caused the MS faithful to spend a few billion dollars on the next WinWord release would qualify as the most productive programmer of the year.
Re:could this be possibly be more useless? (Score:3, Funny)
Huh? What are you talking about!?
Now I suppose you're going to call the "Man-Month" measurement of a project's size some kind of myth!!
Evaluation: (Score:3, Funny)
Re:Evaluation: (Score:4, Funny)
And when Ingrid Insightful finishes her day job, she heads off to her night job at the freak show as the bearded lady
Re:Evaluation: (Score:5, Funny)
Other useful metrics:
Spelling errors per line of documentation
Size of chopstick collection
Volume of spam on harddrive
How many years out of fashion clothes are
Months since last date
Weight of programming manuals in personal collection
Accumulation of fast food and junk food detritus on keyboard
How long to gnaw leg off to escape meeting
How many minutes can talk in jargon and acronyms alone
Number of hours will voluntarily work if just left alone to do the damn thing
Age of most out-of-date, yet essential, book and when it became out of date
Serverity of unintelligible handwriting because everything is usually typed
Increase in heartrate when new technical journal arrives
Depth of paper, notes, cans, wrappers, computer bits, et al piled on desk
Ability to quote from any Monty Python show, movie, recording, book, without error.
Proportion in size of editor macros relative to actual code
$ (is what matters) (Score:4, Insightful)
In a different setting, it's not as clear......
Re: $ (is what matters) (Score:2, Insightful)
Re: $ (is what matters) (Score:3, Interesting)
Oh yeah, all those people who made/created Linux are completely unproductive.
The big problem with any of these measures is you're measuring the wrong "product". Computer code isn't a product, it's a means to an end. Computer code is the final instantiation of an entire process from planning, to coding, to testing, to execution, to refining. First off, the version 1.0 of almost any program isn't the final product (fortunately). Second, wonderful, bug free code accessing the worst structured database is still a terrible application.
So, the idea of evaluating productivity by looking at the code is just plain silly. Evaluate the project.
A better measurement is... (Score:5, Funny)
As far as "what makes a programmer productive", I know what makes a programmer unproductive... reading Slashdot all day. Back to work, all of you!
Re:A better measurement is... (Score:2)
Dijkstra on LOC (Score:5, Insightful)
Agreed. I think it was Dijkstra who argued that if Lines Of Code are counted, then the number should be viewed as a liability rather than an asset. That is, LOC are not something we produce, but something we spend.
Re:A better measurement is... (Score:3, Insightful)
Also, I would also have to disagree with the article. The following comment really isn't true: "[h]is code is shorter and simpler, and simplicity is almost always better in engineering". The larger code code be contained in well thought out objects, or functions, that make the reading of the main Objects, or functions, simpler to read, and the main bulk of the code if well engineered could also be reused easily.
In his above example, Danny's code may not be anymore reusuable than Fred's. Danny's smaller number of lines per code could be result of not taking into account all necessary possibilities, or not thinking about possible future problems.
The size of the code just doesn't matter. What does matter is how well the code is thought out and commented (both insertions and deletions of code). Well thought out code usually can produce some reusuable code and/or design patterns. Personally, as a rule of thumb, I don't like to write code more than three times for a given task or problem--unless I absolutely have to write it more times.
how about... (Score:2)
Re:how about... (Score:2)
One company makes the product in 4 weeks. Looking at the JSP's is a nightmare (because all the code is within the JSP's).
Another company makes the product in 8 weeks. The JSP's are all done with taglibs, and the entire site is used with EJBs.
The first product is done twice as fast. But the second product is ten times easier to maintain, and fully scalable.
Which would you prefer?
As a disclaimer, if you want something simple and quickly, sure the first way is the way to go, but for anything that I'd consider a "product" the second way is better.
Re:how about... (Score:2)
Did I miss something ? (Score:2, Funny)
What else is new ?
Programming truism #19274 (Score:5, Insightful)
Its not perfect (ideally code is not quite optimized to perfection - its nice to trade a little size for readability) but it seems roughly accurate.
Re:Programming truism #19274 (Score:5, Insightful)
Ben
Jeebus, talk about stating the obvious (Score:4, Interesting)
Phew, what a long winded way to say: KLOC [analogx.com] in any form is a useless metric.
I was rather hoping for positive suggestions regarding better alternative, and especially some shiny references to back them up for when I take them to my boss.
The best metric I've found is simply "Time until feature complete". Just that. Elapsed time between a feature being requested and it going live in the field with no bug reports coming back. Anything else is largely bunk. Trouble with that is that it's very hard for twitchy bosses to deal with the interim stages. "Time to code complete" is easier for them to monitor and deal with, but as anyone who has actually supported a product will know, that's only the beginning of a piece of software's life. Push the time to code complete back by a week, and you can save yourself month of grief later. ;-)
Alas this doesn't cover much new ground.... (Score:3, Interesting)
(How do I know Danny does more work just because he does the same amount of work in less code. Its like the author follows some reverse logical mistake that he is harping about.)
A very interesting book on this subject is "The Psychology of Computer Programming" by Weinberg. It will get you thinking! I think the "Mythical Man Month" also discusses related topics.
Thanks
It depends a lot on Personality (Score:4, Informative)
There are various types of programmers around. We've certainly worked with a wide selection. Over the years, we've come to realize that programmers can be divided into various "personality types". You don't stay the same personality-type your whole life though -- as you develop and learn, your approach to programming changes and that change is visible in your code. We're going to look at various functions and how programmers with different personalities would write them.
MacHack attendees have normally been around the block a few times. That means they have learnt various things, like when you're going around the block, it helps to watch where you're going, and be driving a tank. We know that a function has important responsibilities. It needs to check every error code, keep track of every byte it allocates, and that function needs to know how to cope with anything that happens, cleaning up perfectly after itself and returning an error code which explains what went wrong. But in order to write code like this you have to have made mistakes and learned from them. We know we have...
Good Starting Point (Score:2)
I think the only other items I would add to this are pursuit of programmer metrics include
It's hard to measure that, because the superficial situations are identical: programmers enthusiastically extending some well designed code on one hand, and a set of programmers grumbling about fixing things in a poorly written chunk of code.
Pointless metrics again (Score:3, Insightful)
One of the things that makes good programmer full stop is not worrying about trying to measure the imeasurable.
Cheers,
Ian
Old news (Score:3, Insightful)
It compared the lines of code and number of bugs to the salaries. Of course it said it was cheaper to hire a super programmer. But, it found that the only difference between the average programmer and the incompetent programmer was the number of bugs generated, not the lines of code.
People need to be reminded of the high cost of debugging. It takes a long time to track down a bug.
What makes a programmer highly productive . . . (Score:4, Funny)
BEST: Number of New Features per Day (Score:3, Insightful)
Optimize on your own time. All the non-developers care about is what gets into the final product, and if you meet the list of desired features, then you're productive. End of story.
Near- total idiocy (Score:2, Interesting)
"Danny's code probably will be easier to extend and modify, and likely will have a longer lifespan, because of its compactness."
This is potentially utter rot. If you make something "compact" then you're quite likely *using* the language to insert every idiom you can think of. That makes code *unreadable*, not productive at all.
(Yes, I've been known to argue in favour of using prgramming languages' idioms before now, and more to the point I expect folks who dare to look at my code output to be able to read it, or else have the decency not to criticise it) but there are limits.
The alternative is that he's implemented a sufficiently different top-level algorithm - and at that point you're not comparing like with like so you can't say one person is any more productive than another.
However, you could introduce "amount of desired algorithm implemented per day" into the formula for productivity calculation.
Comment your gd code!! (Score:5, Insightful)
As I shouldn't even have to say... commmenting your code improves productivity A LOT. Some people say you shouldn't comment code in a commercial product because then you can easily be replaced. My response to that is, why don't you do good work then you won't have to worry about being fired?
If I had an employee who's not commenting his code, that means the next coder that tries to change something is going to spend a bunch of completely unproductive days just trying to figure out what's going on. I think I'd fire the employee because of his incompetence and the amount of time/money he going to make me waste.
Re:Comment your gd code!! (Score:5, Insightful)
Point taken, but I rather prefer writing self commenting code. What's better?
And anyone who complains that it takes too long to type "ISDN_Terminals_Per_Trunk" compared to "data" really needs to take a cluecheck about the relative amounts of time spend reading and writing code compared to comprehending and fixing it. ;-)
Comments by naming (Score:4, Interesting)
Similar experiences right now... (Score:4, Interesting)
They later hired me.
It is now my job to maintain, expand and rewrite his original code as the device gets further from the prototyping stage.
Here's some metrics for you:
4000 lines of C code
Avg. Variable name length: 3 to 4 characters
Avg. Function Name Length: 3 to 4 characters
Total number of functions (not including state-machine functions): 9
Amount of documentation: nearly 0. Comments are laughable.
Total number of functions, including state-machine functions labelled from stsws0 through stsws30 - 40.
Total number of constant values used without #defines or assigned names: Too many to count.
Amount of documentation of constant values that aren't obviously for buffer/scratch space, but actually do something important: Zero.
Amount of dead code: Current investigation indicates somewhere between 30% and 60%.
Amount of dead code interspered with live code, so it's really difficult to work out what's a dead function, and what's live: All of it.
Level of interweaving of dead code and live code: pretty damn high.
Use of pound-defines for code switching and giving alternate code paths: Zero.
Use of pound-defines to switch blocks on and off that really you want to keep on ALL THE TIME (particularly as the app crashes if you turn them off): 10
Interesting idioms:
-- Use of pound-if(0) and pound-endif to bracket (useless) comment sections, eg:
pound-if(0)
This is a comment.
pound-endif
-- Use of a while loop to do error handling. Eg;
while (TRUE) {
if (condition) { error = 5; break; }
break;
}
if (error)
Number of pound-includes that are actually totally unneeded:
5.
Number of Windows 3.1 programming idioms used: 2 found so far. In a piece of code that *requires* NT4 and as such is Win32 only.
Other interesting idioms: Massively nested if's EVERYWHERE. Very little modularisation. Grabbing an HDC at that start of the app and not letting it go until shutdown, without specifying a Class DC.
The guy REWROTE FROM SCRATCH button controls and edit controls, using WM_MOUSExxx message and WM_CHAR handling, as part of the main frame window. Each edit/button has a separate cut/paste if statement block to handle it. There are about 80 controls on the main screen. This code is cut and pasted for each single control.
And for the final piéce de resistance;
Total number of local variables used: ZERO. 0. Nada. Zilch. EVERYTHING IS A GLOBAL VARIABLE.
Problem w/ design docs (Score:4, Insightful)
You should strive to make your design docs just good enough for the people who'll be reading them -- the maintenance programmers, who will also have the code. In other words, the design docs are the cliffnotes to the code. The code is always the authoritative design documentation.
BTW, I STRONGLY recommend reading Agile Software Development [aol.com] for anyone who's seriously interested in these issues.
What my company does... (Score:2)
We have engineers that may spend a day or two writing out a document to assist their coding the next day. That isn't considered a ding in their productivity. If anything, providing an insight into their code before they write it (psuedocode, not commenting) has been very helpful, particularly when the other engineers need to code parts that talk to each other.
I honestly have no idea how this would scale to a >50 employee company. If it's really that important to make sure you're squeezing every ounce of productivity from your employee, I'd be concerned about where exactly that company is heading. Seems like investing more time into pre-planning would be more fruitful than lighting a fire under an employee to attain 'measurable goals'.
In some ways, I'm glad I didn't choose programming. It's quite frustrating to predict when you'll have code you've never written before.
Over-valueing comments (Score:5, Insightful)
However, I would rather have a programmer who writes easily understood code but doesn't document it well than one who writes well documented but overly complex code.
I've worked on large projects where there was nearly a 1:1 ratio of comments to code, but the comment didn't help you see the big picture because the parts of the application were too far abstracted from reality. And the code was written in strange ways that made it hard for other people to understand.
In summary, the code can and show be written so that most of it documents itself. If the application is well designed and the code is written well, the need for a lot of in-code commenting goes way down. This is assuming we're not talking about assembler, which in my opinion should have a nearly 1:1 ratio of code/comments.
Quantity vs. Quality (Score:2)
Another important feature of comments is a changelog-ish sort of function whereby each software change is documented within the code. Where I work, all of us in Sustaining Engineering write in a bug number with each change that we make so we can go back and find why that change was made later on when we look at the code and wonder why the heck we did that.
These are a few good rules of thumb in my experience at least..
Ben
Re:Self-documenting code is a pernicious myth. (Score:3, Insightful)
You claim that code cannot be tested unless it's documented. Then how do you test the comment that is supposed to be describing the code? It's just as likely to be wrong as the code is itself. Example:
// This code prints foo to the console
printf("bar");
Why should the comment be the true authority? It's no more an authority than the code. I've seen countless examples of the comments being far out of date compared to the code.
The point is that simple code *is* obvious and doesn't need any further comments.
I wasn't talking about the design document, I was talking about the inline documentation, aka comments. I think all code should be designed before it's built and that design should take the form of a document, but that is not the same discussion we were having.
I've got to get my boss to read this... (Score:2, Funny)
Now, if I can just get my boss to endorse this programming style...
What about future re-use of the code? (Score:3, Interesting)
This article seems to raise more questions than it attempts to answer... This is not surprising because the "programmer productivity" has been the subject of many debates.
The proposed definition ("Ability to solve customer problems quickly") seems to ignore several of the good points mentioned earlier. For example, one can be able to solve a customer's problem quickly with an ugly hack. Some undocumented spaghetti code full of black magic may be able to solve one problem quickly, but it would be impossible for anyone to maintain this code later. Or to re-use it for solving someone else's problem.
So who is more productive? The one who solved the problem quickly with an ugly hack or the one who solved the same problem by writing clean, documented and re-usable code?
So it is a pity that what appears to be the conclusion of this article has thrown away the notion of clean and well-documented code mentioned earlier. Maybe a better (but more complex) definition would be: "Ability to solve customer problems quickly and to solve future, similar, problems in a quicker way". The drawback of this definition is that it cannot be measured on the current project, but only when the next one appears.
Not just hypothetical (Score:4, Interesting)
I want to add another angle... I managed validation. I viewed our job as reducing 1-800 support calls to zero. In the end, support costs need to be rolled into productivity numbers for develpers also. A couple of support calls from a single user can easily make the gross margin for the sale to that user negative. (And for you "free beer" programmers -- same thing applies, wouldn't you rather write code than spend time supporting users?)
And a closing note: A wise manager once said: "Obviously you want smart, productive people on your project. Note that dumb, unproductive people are relatively harmless, because they are not productive enough to cause much damage. What you need to watch out for are dumb, productive people."
i agree (Score:2, Insightful)
Unfortunatly, I'm doing consulting work and there's something about the client prefering to pay for time on site. Suggestions for beating these concepts into management?
Unask the question (Score:5, Insightful)
Having any defined metric is (IMHO) a Bad Thing in the long run, for the simple reason that people will sooner or later start gaming the metric. If you reward lines of code you get lots of lines of code. If you reward feature points you get lots of features. For a while I tried more abstract things like "user satisfaction," but that started drifting into the "The Customer Is Always Right" syndrom, with all the feature creep and bloat that goes with it. Using "my satisfaction as your manager" is even worse; brown-nosers are a danger to anyone undertaking a team effort with any element of risk.
So I started wondering: do I realy need to measure productivity at all? Why do I care? The bottom line was, I don't care. I'm not interested in "producivity" any more than I am in "attendence." At this point, I tell people if you want to know what your score is, play a game, open an on line stock market account, or post messages on a web page that keeps track of karma. In this team, the focus is on getting the job done, not on keeping score.
-- MarkusQ
Ok, so I'm strange (Score:3)
First off, metrics don't "prove" anything. But in any case, this generally doesn't come up because I don't discuss schedules with clients. I've found it is counter productive.
The closest I'm willing to come is something like:
If you think about it, the only reason I wouldn't be willing to work like this is if I expected to fail. Which I don't.-- MarkusQ
Re:Unask the question (Score:3, Insightful)
Agreed. There are all sorts of nifty tricks you can do with objective things like code, mud, starlight, or prime numbers, because you can make statements about them that can be disproved by testing. If you say "most of the time is being spent here" and someone else says "no, the problem is that this routine is recomputing the value of 12 each time" it is posible to test and see who is right.
My objection is to trying to use "objective" metrics on subjects like programers that know you are measuring them and thus can change their behaviour to get "good" scores without actually doing what you want. In general it isn't possible to easily disprove statements in such systems (it would probably make the legal system much simpler if you could) and I object to metrics that pretend you can.
-- MarkusQ
Ancient issue has been addressed before (Score:4, Informative)
Being a "Data Miner" myself, I can certainly agree with the problem-solving-as-productivity approach, rather than the "how many inner joins can I throw at this to make it look like I am busy" approach.
Actually, the LOC as productivity is so foreign to MY thought process that I can not comprehend why anybody in management or in direct labor would bother to think about it.
A dated approach (Score:3, Interesting)
A metric that takes real productivity into account for new projects (the Ingrid example above wasn't a great one since she was maintaining code, not creating it) would be one that measures requirements met versus time. It would of course be up to the manager to say whether the time taken was too long, about right, or less than expected.
A developer that consistently meets requirements with working code, in a timely manner, is a good developer.
Clearly the key to success with this metric is managing your manager's expectations. ;-)
Lines of Code? Wrong, wrong, and wrong again (Score:2)
It never was. Or maybe it was, back then.
Old-school lines of code were assembly instructions, or COBOL statements (which map fairly easily to assembler anyway).
But all this has changed, a lot.
Software these days is about components, about reuse, about APIs. Reinventing printf gets you more lines of code, but is useless and stupid (in most cases).
Object orientation throws productivity into a whole new ball game. You should get productivity points for reusing code, not for rewriting. So it's never, hasn't been for some time, about lines of code.
Even function points are better.
But anyway, is productivity such an issue for programmers?
Productivity is a business concern, and makes sense in a business environment. And businesses don't (shouldn't) build software by throwing programmers at it.
Businesses build software through a process that involves requirements, analysis, then design, test suites, and then coding and testing and documenting.
What part of all this does programming involve? 15%?
Forget lines of code. Forget kindergarden productivity measures, forget subjective analysis into what is "good code" and "documented code". You document BEFORE you code. And it is "good code" if it implements what is documented.
Anything else is just fooling around.
Time and Money (Score:2, Interesting)
Sometimes really good code is just not worth it.
Sometimes code is not worth it period. (There are better ways to solve the problem than a custom process)
If you don't make enough money to pay for the time- you won't be in business long. (At least as long as your software engineers are willing to live off their own credit cards and pick up company expenses.)
.
I'm not impressed (Score:3, Interesting)
While I admire the author's brave attempt to establish a new model, I must conclude that he has failed: Applying a quantitative measurement to a qualitative phenomenon is absurd. Do we judge a painter by the number of brushstrokes and conclude that Rothko is lazy and Van Gogh is a diligent worker?
There are many qualitative components by which a programmer can potentially be judged: sheer output, ability to debug others' code, ability to have code debugged by others, ability to create understandable extra-code documentation, affinity for the lifestyle of the person doing the judging (i.e., likes to go out for a beer after work, roots for the same professional sports team, etc...), concentration skills, hygeine, and so on. Attaching metrics to this is nothing short of masturbating one's ego. There is a wonderful allegory to this in Robert Anton Wilson's Schrödinger's Cat trilogy, in which a self-important researcher attempts to rate a woman's orgasm using measurements on scales developed by the doctor himself.
Fred Fastfinger (Score:2)
Amen, brother. I was the poor bastard who was the "next programmer". Fixing "Fred's" poorly written and worse documented code did do wonders for my skills, however.
The real question (Score:3, Insightful)
That's the dilemma facing project managers-- is it better to "get it working now" or "ease extensibility/maintenance later." There is no hard and fast solution. It's different for every project, and often misjudged, in part because you can't see into the future to determine its lifespan. Of course everyone wants two Dannys who get done in 5 days, but that's not the real world scenario.
Productivity (Score:2, Insightful)
Measuing the productivity of a software "designer/engineer/coder" or whatever you want to call them, is a very difficult thing to do. On our current project we are using a third party tool that is riddled with bugs, unfortuantly due to management desicions we are unable to ditch the product and search for a different tool. However, my team has remained highly productive during this past month while working with the vendor to solve the issues.
Have we produced many lines of code? Not really, probably around 9000 lines between the 6 of us over the past month, that is about 1500 lines per programmer... in over a month. According to any logic using "lines per day" or anything along those lines, we are in horrible shape. However, we have been solving many of the issues with the vendor, scouring over lines of code to ensure that the tools are working correctly, changing and tweaking our testing classes (Java) to ensure that everything is truly working the way that it is supposed to be.
Now, with about a month of time wasted according to typical programmer productivity analysis, we have a decent library of functionality built up (or easily migrated into a library), we are very familiar with the product that we are using and the APIs, and will probably come in on, or before schedule.
Was that time wasted? Were we unproductive? I would say no to both of those questions. Yes working with a vendor with broken software was frusterating and time consuming, however we now have an intamite knowledge of a third-party "black box" and we have, in the process of working with them, built up a suite of test cases that will help us immensily in the near-term future.
But, we only turned out 1500 lines per programmer in a month you say. However do to all of the debugging work, and API "scouring" we have done, we will probably be able to turn out closer to 500-1500 lines of good well documented and working code every day or so.
Well my point is simply this: Lines of code per day is simply not a good analysis. The best way to determin productivity is on a per project basis. How is the project coming? Are the objectives being met, are you solving the problems that are coming up in a timely fasion? There is no final answer, it must be evaluated per-project, per-team, per-company.
-ryanSo incisive.... (Score:2)
Oh...wait a minute...this would be old news if it were posted on slashdot circa 1975, it's positively fossilized now. Sheesh.
If only all managers could understand... (Score:2)
I have seen a lot of good programmers code for hours, but I have also seen truly gifted programmers walk around and "process in the background", then go back and present a solution just as valid but with much less "machine time".
Sir_Haxalot
And the implications of taxing development -- art? (Score:2)
For me software is a consultative and artistic endeavor.
I don't know how "science" ever made it into the moniker -- when they tax architects perhaps it would be categorically fair.
Quantifying the qualitative... (Score:3, Insightful)
Which is more valuable, a programmer who churns out 1000 lines of code/day but very reclusive or the one that does 500 but is also good at communicating project directions with others?
Which is more valuable, an inexperienced programmer who learns quickly or an experienced programmer who doesn't?
if you want to know how good a programmer is to ask them the right questions. I'm not sure exactly what those questions are, it depends on what you want out of them. But I've been on many interviews and it's amazed me the vast differences in interview quality. People who are trying to measure the quality of a programmer by "lines of code" are setting themselves for lots of problems.
I think I was asked once to estimate lines of code I've written and I had NO idea. Frankly if somebody did know the answer to that question I'd be concerned. It sounds like somebody who's too busy keep track of the metrics that imply their skill rather than actually doing good work. These are likely the same people who are staring at the clock for the last 15 minutes of the day, constantly estimating the minimum amount they need to do to get by.
Lines of code (Score:2, Funny)
Never again would they want more lines of code.
Deleting Code (Score:2, Interesting)
Can't measure... (Score:3, Informative)
if( 1 == x )
Runs fine, looks butt ugly, but works. Is this of quality? As long as it works? As long as its easily readable?
What about a function that does:
int x ( int a, int b ) { return a/b; }
Runs fast. Can break.
Its all subjective baby. You can't measure it by speed of coding, by lines of code, number of functions, number of bugs..etc... Its a matter of the employeer of the programmer being happy with his output.
Next questin
Pascal quote (Score:5, Insightful)
-- Blaise Pascal
If anyone deserved to have a programming language named after him, it was the originator of this quote. I just wish it had been a more concise and expressive language.
The Mythical Man-Month (Score:5, Informative)
He Missed the Point about LOC (Score:3, Insightful)
Source Lines of Code (LOC or SLOC) are used, by management, to get an understanding of the overall productivity of software engineers in general. It is not an end-all,be-all rule regarding software engineering.
If you take a sampling of 100 good programmers, given clear requirements, and measure their performance, you will be able to determine the overall productivity for a single engineer on a per day/week/month/year basis. This allows managers to make some determinations regarding project planning, enhancements, changes, and yes, to some degree, the performance of engineers.
For example, if I know that my engineering group of X people are capable of contributing 1000 LOC per person per month (per man-month) to a project, then I can better estimate the cost and schedule of a new project. The project's scope is determined by detailing the customer's desires, and developing a break-down of capability. (Things such as R&D, training, and new technologies are identified and have an appropriate risk factor associated with then).
A LOC estimate is associated with each capability, which consequently will produce a timeline and cost.
What the author should have really reflected upon was not how to refine the software productivity metric, but rather how to refine the application of that metric.
something missing (Score:3, Insightful)
Function points? (Score:3, Informative)
This is a recycled article. (Score:5, Insightful)
This guy misses a lot... (Score:3, Interesting)
How fast is the compiled program
How big is the compiled program
How easy is the source code to read
How stable is the compiled code
How secure is the program
How complete is the feature set
These are all about software quality, not quantity, though. Once you've measured qaulity, the only measure I can see for quantity is, "Did ya get the job done?" The key to measuring a programmers productivity, I think, is to have the programmer keep a log of what he's doing. With that log, the company can insist on improvement, a maintained level, give bonuses for productivity, etc. The only issue I could see with such a log idea is that the higher ups will become so obsessed with the log, and what the programmer is allowed to claim as a job done in the log, that the programmers won't be able to do their job. Oh, well, it was just an idea.
BlackGriffen
True Productivity (Score:3, Insightful)
If you need comments... (Score:3, Interesting)
My personal measure of coder productivity is as follows:
1. Take all the produced code.
2. Remove all the comments.
3. Present each function to a third party who is unfamiliar with the code, and ask them to explain how it works. If they can't, delete the function.
4. If you have anything left, remove all formatting except linebreaks, and count the *distinct* lines of code. (Bad coders tends to cut+paste, which would lead to overcounting.)
One example (Score:3, Interesting)
I could go the easy route and check every array index in the first array against every array index in all the other arrays. For all I know this is the most efficient way to do this.
But, instead I'm going to research some algorithm books and see if I can't find a more efficient way to retrieve the common elements.
I may very well end up with something that takes a lot longer to code and has less lines of code than the brute-force compare-every-element-against-every-other-element method. But if the payoff is faster, tighter code, then my research and extra coding time will have paid off. However, to the untrained eye, it may look like I'm spending more time to produce less code.
If you are a manager reading this, remeber, the best solution may take longer and contain less code than a suboptimal solution! You have to think hard if you are going to try to quantify this - because nobody knows off the top of his/her head what the best algorithm for everything is. If you have a programmer who regularly researches the efficiency of the algorithms they use you will probably end up with a lot happier customers than if you just have people who bang out code without thinking hard about what they are doing. Unfortunately, doing things the right way makes the programmers job harder to quantify.
Does anyone count lines of code anymore? (Score:3, Informative)
The larger teams also have code reviews, so if a programmer's code leaves something to be desired, they can say so in those meetings and send him off to fix the problems they highlight. Said meetings understand that programmers of varying abilities work on the team, but they allow the team to address the most obvious shortcomings in someone's code.
A testing cycle is also required to insure that the programmer's not just saying he completed the requirement. Not much point in submitting code as complete if it doesn't operate as per the requirement's specification.
true enlightenment (Score:5, Funny)
Coder: 1
Boss: [next day], how many lines did you do today?
Coder: 1
Boss: [day 3] how many lines did you do today?
Coder: 1
Boss: how come you only do one line per day
Coder: Actually I'm working on the same line.
Boss: How many lines is the damn program?!?
Coder: 1
Boss: You're programming in Perl again arent you...
Ah, so that's why so many companies think... (Score:3, Funny)
Useful information content (Score:3, Interesting)
For the code, the metric you'd actually like is something like number of useful, novel expressions.
Copying a section of code doesn't add anything, because the lines aren't novel. Any changes you make to the lines do count, though. Making an existing block of code into a separate procedure adds a novel expression, and the expression is useful if you call it from multiple places (i.e., if the procedure is a useful abstraction). Calling a procedure with a new set of arguments is novel and generally useful.
Basically, you want to know how long the day's work had to be, given the pre-existing code, if it was done optimally.
If you add a penalty for making the code needlessly long, then a day spent reworking bad code to be shorter by combining common expressions, removing extraneous computation, etc, will also be considered productive.
For the documentation, it is easier to consider but harder to quantify. You are now measuring the number of correct and useful pieces of information that a person would get out of reading the commented code. The information may, of course, be obvious from the control structure, implied by the variable names, or actually in comments; since comments add to the length of the code without adding any functionality, using coding idioms that the reader will know (because they're part of the company's style guide or common throughout the code) and informative names is better than putting in comments, unless it is impossible (which is frequently the case).
Of course, it's hard to quantify "pieces of information" and hard to judge objectively what can be gotten out of a block of code, which is one reason this isn't something you can set up cvs to do each day or something.
This means that the ideal block of code, which should be counted as the most possible for a given problem, has these properties: it (or an equivalent block) has to be there in order for the project to do what it's supposed to do; it is not replicated, in whole or in part, anywhere else in the project (if it did, it would do better to call the other part); its behavior is clear from the names of the procedures, variables, and types; any common algorithms are implemented in the standard ways; and unusual algorithms are commented explicitly.
I think this metric would measure productivity effectively. Of course, it doesn't help productivity to actually try to measure it.
Measuring coders' productivity just doesn't work (Score:4, Interesting)
Number of lines of code written, highest score wins. In short, why write in 100 lines what you can write in 1,000?
Number of lines of code written, lowest score wins. You end up with your own obfuscated coding contest. You might also find people rewriting other people's work, redesigning APIs and other infrastructure components, for no reason other than to lower their own score. This can lead to total chaos, fights in the parking lot, etc.
Number of good lines of code written a month. What's the definition of "good," and how subjective is it? If it includes comments, then how is the usefulness of a comment determined? I've seen developers write more comments than code, and in the end the comments said nothing useful that would've helped a new developer maintain the code.
Number of bugs fixed in a month. The programmer who spent a month researching the sev 2 bug that was affecting system availability or data integrity for the last three months isn't recognized for his/her achievements, while the intern who fixed 100 bugs pertaining to typos on the website and in the documentation is rewarded.
Number of bugs created in a month, lowest score wins. Nice idea, punishing people for creating bugs, but people might get so paranoid about causing bugs that the turnaround time for code is obscenely high.
Code complexity metric, lowest score wins: All this proves is that the programmer's capable of writing non-complex code but says nothing about the documentation for the code, the overall design of the component or subsystem the programmer was working on, etc.
Number of tasks completed in a month. This screws the guy who's got a hefty task that cannot be divided any further or the programmer waiting on the sysadmin to install the necessary development tools so that he/she can actually get started.
Customer satisfaction. The customers are pissed because the website is unstable, but the rest of the back office system is running perfectly fine. In the end, everyone -- the back-office developers, the database guys -- is punished when only the website people should've been put on call center duty for a week.
Number of customer issues resolved. There's a great incentive here to solve issues with kludgy hacks which, in six months to a year, might leave the company with a very flaky, unmaintainable system.
360-degree input, or "Mutually Assurred Destruction". This was a system IBM used -- still uses? -- where your peers, some picked by you, some by your manager, would fill out a survey and offer opinions about you. The manager would then piece it all together and come up with a result. Like Dilbert called it, it's "mutually-assurred destruction," although I saw it work the exact opposite way many times.
There's so much more that goes into developing and delivering software than just writing lines of code. And the number of lines of code written isn't all that significant if the design sucks, if the documentation is unusable by the people who need it, if the call center people supporting the thing aren't trained properly, or if the systems supporting the website or the database are unstable. How do you put a score next to a name when many of the things contributing to that score are subjective or out of the control of the person being scored? We're not building CD players here!
Was that all? (Score:4, Insightful)
He also fails to recognize that programming is a group activity, where one person can be seemingly unproductive, but in reality being vital for the productivity of the group. Typical such persons are mentors, which spends some of their time helping others. Mentors may not produce a single line of code, but still be the most valuable person in the group.
Alistair Cockburn does in his modern classic "Agile Software Development" state that software development is a "Cooperative Game of Invention and Communication". Therefore the productivity is best measured at the team level, since they are, in the end, cooperating.
Also, I think it is quite clear that use cases, or user stories, or whatever you wish to call them, are the best way to describe the wishes of the customer. Fulfilling these wishes are ultimately the only thing that matters.
So, I would say that the number of finished use cases per unit of time, for the whole team, is by far the most meaningful measure of productivity.
Mats
it's called Software Quality Metrics (Score:3, Informative)
For example. In grad school, we took the 1992, IEEE Standard for a Software Quality Metrics Methodology, along with GNU Flex, and wrote a program that would slice-n-dice C & C++ programs against a table of measureable metrics for code readability and reusability.
Of course, we had a blast testing it against winning entries from the 9th International Obfuscated C Code Contest [ioccc.org]. But we also noticed that there were just some things that it would never be able to test. For exmaple, while our little app spotted code that was uncommented, it could not tell us whether or not the comments were useful or relevant.
Point is, judging code and productivity is always (or at least until HR offices are equipped with Beowulf's) going to have a subjective element. Because lets' face it, when it comes down to it, many bosses really only care that the job gets done on-time and under-budget.
Or what's that great line from the movie "War Games"
Utility versus Satisfaction (Score:3, Insightful)
Definition:Productivity, '2 a : the act or process of producing b : the creation of utility; especially : the making of goods available for use.' from Mariam Webster
Premise: Productivity cannot be measured except by creation of utility. Utility can be defined as a marginal increment of value. Value can be defined as a unit of production. Productivity then is a measure of increased value. Definitions of value have been attempted from Aristotle onward with varying degrees of acceptance. For business purposes value is found in the bottom line and is predicated upon Generally Accepted Accounting Practices.
If we put aside the idea of a programmer being made to be 'highly' productive as a pipe dream then increments of utility can be put forth as the only available measure of productivity. For example I find I'm more likely to be 'highly' productive the more people like me, do what I want them to do and give me what I want.
If we accept increased utility as a definition of productivity then the final product as it is defined becomes the final abitrator of value. This implies a Goal oriented approach to value based upon measurable increments to utility. This suggests any one programmer is capable of productivity only in so far as s/he is capable of adding to utility.
If this simple definition of productivity is looked at from the view point of Open Source an interesting phenomenon arises in terms of the artistry of programmers. The Renaissance and post Renaissance periods produced leaps in Science and the Arts something akin to what we're presently experience. It's been suggested the creation of perspective drawings birthed the industrial revolution by providing schematics that made possible the production of the machinery of industrialization. A critical aspect of the Renaissance and the eras that followed upon it allowed for the free borrowings from the works of others. Those given to 'copyrighting' their material had little recourse, famed lutanists would hide behind curtains so no one could steal their chops. Bach, Shakespeare and others freely borrowed lines and more from their contemporaries and those who came before them. Bringing this rant to a close it remains to postulate whether the Open Source movement, in multipart harmony, provides a more efficient model for productivity? Well doh!
Re:No actual suggestions.... (Score:2)
Editors: Please say no to features like this in the future! Use your head. It's probably better for this guy's ego anyway to have one of you tell him his article sucks rather than all of us. :)
Re:What a steaming pile... (Score:2)
if you think that anyone will be able to get what you were doing 2 years after you left/were replaced - your fooling yourself.
within 2 years
Yet your function is still there.
If your code is clean
And I for one
Commenting your code has been around since the late 70's/early 80's
Not to mention that it might be nice to know where your incoming variables are coming from
or what they are expected to do.
$loop is pretty self defining
so is $array
but having a comment '// This function pulls an array of repeated fields, and outputs them to a report'
took me only about 4 seconds to type. and saves someone the time of huting through other code to see what REFERENCES your funcion.
*emote*gets off his horse*/emote*
but granted
Re:Measure user happiness (Score:2, Funny)
IIRC, there was a Dilbert comic about this a few years ago: PHB decides to change the work metrics, and selects #OfBugsFound/Fixed. Wally, resourceful as ever, is seen a panel or two later saying "I'm gonna code myself up a new minivan this afternoon."
PhilMills