It's Not About Lines of Code

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.

Comments

A better measurement is...

[Jeremi]

Problems solved (or tasks accomplished) per day. Whether you write 500, 5000, or -2000 lines of code to solve the problem is irrelevent, since the code is only a means to an end.

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:Classical measures of productivity

[ackthpt]

Why programmers get grey hairs:

"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."

What makes a programmer highly productive . . .

[Pike65]

; )

Re:Evaluation:

[Anonymous Coward]

They should evaluate programmers by the length of thier beards. =)

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:

[ackthpt]

They should evaluate programmers by the length of thier beards. =)

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

Re:I have!

[Skidge]

This is why you tell managers numbers that will make them comfortable with your progress, no matter if they are really accurate. The better your managers feel about your work on the project, the better you will feel, since they will stop bothering you as much. In other words, arbitrary and meaningless questions deserve arbitrary and meaningless answers.

Of course, you still need to finish everything on time or your arbitrary and meaningless answers won't work the next time. :)

true enlightenment

[archen]

Boss: How many lines of code did you do today?
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...

Re:Classical measures of productivity

[Skyshadow]

Well, in fairness, there's a good reason why you can't just leave a developer to go on a six month project.

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.