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

Classical measures of productivity

[T5]

They just don't apply to this art/science. Would Michelangelo's boss have put him to task for square inches/day or pounds of statue/week output?

Re:Classical measures of productivity

[Sc00ter]

If I requested a statue of say, myself, I would expect a completion date. He should be able to figure out how long it would take to finish a statue of somebody my size. Equally he should beable to finish a painting of a subject that's been selected prior to him starting his job. Just as a programmer should be able to estimate how to finish a project if he knows what's involved up front. Of course this isn't exact, it's within a few days or weeks, but there should be a ballpark figure, also, changes to the design should be expected to set things back.

Re:Classical measures of productivity

[ivan256]

Yeah, that's great, but what manager works like that? No manager would ever say to me "John, how long would this take you?" for a project with a 6 month or 1 year time frame, and then leave me alone for 6 months while I write code. Managers want progress reports and statistical measures to reduce the risk that that they might get fired when the project they're managing fails. That's where the boneheaded requests for the "number of lines of code you've written this week", or "number of bugs you've fixed this week" come from. It's hard to look at an unfinished piece of software and know how it's coming along, but it's easy to look at a painting or a statue that's in progress and see work being done.

Re:Classical measures of productivity

[Darth_Burrito]

To: Mike
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

Re:Classical measures of productivity

[loydcc]

If I remember the story correctly... The Pope wanted Michelangelo to send his portfolio for consideration before giving him the Sistine Chapel. Michelangelo drew a circle freehand on a slip of paper and sent it off with a courier. The pope was insulted and sent the courier back with an admonition to send a real portfolio. Michelangelo sent the circle back. The pope then traveled to confront Michelangelo. Michelangelo's response was something on the order of the circle is perfect. If he could do better freehand he should do the whole ceiling his own damn self.

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.

could this be possibly be more useless?

[nsqtr]

Dude, buy a copy of DeMarco/Lister's "Peopleware", original edition is circa 1985. Your "revelation" is old news and you offer no substantive recommendations for actually helping management measure or actuate programmer productivity. The Peopleware book is factful and entertaining and reaches no better conclusion than you have. After 17 years, don't you think your postulations should improve on previous work. Have you done any research on prior publications?

Re:could this be possibly be more useless?

[Amoeba Protozoa]

I would argue that reiterating something that might not be common knowledge to everybody or perhaps even to one's self is not a waste of anyone's time. It can only help to raise awareness of a particular view on an issue that not everybody may have knowledge of.

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

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! ;^)

Comment your gd code!!

[MongooseCN]

I work on contracts for commercial software and it is amazing how much code people can write and not comment it. I had to change the functionality of some program once and it took me 5 days to write 3 lines of source. Why? Because I had to wade through code with variable names like "int32 data[7];". As a bonus there were hardcoded numbers to the variable. I had to do hex dumps at one point to see where the data was being used and how.

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!!

[Rogerborg]

• it is amazing how much code people can write and not comment it

Point taken, but I rather prefer writing self commenting code. What's better?

• int32 data[7]; // Number of ISDN terminals per trunk. But then I should really comment every use of this monstrosity as well
• int32 ISDN_Terminals_Per_Trunk[NUMBER_OF_TRUNKS]; // Why would you need to comment this?

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. ;-)

Over-valueing comments

[kevin42]

Don't get me wrong, commenting your code is a must.

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.

Unask the question

[MarkusQ]

There are many other ways of measuring programmer productivity. As a programmer and manager-of-programmers, I hold that they all have one feature in common: they are worse than useless.

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

Dijkstra on LOC

[devphil]

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.

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: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

Pascal quote

[PhilHibbs]

"I have made this letter longer than usual, because I lack the time to make it short."
-- 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

[Animats]

This guy clearly hasn't read The Mythical Man-Month. He should.

I have!

[barzok]

About 2 years ago, I was working on my first major project and the project manager called me one day out of nowhere to ask where my progress was (normally we covered this in a weekly meeting). 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?" 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!

[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. :)

Re:I have!

[Mike1024]

Hey,

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 := sqrt((1/3)*(x+5))

to this:

Foo := X + 5
Foo := 0.333333 * Foo
Foo := sqrt(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

This is a recycled article.

[Webmonger]

The article originally appeared here last week. Sheesh. Don't pretend it's an original Slashdot article if it's not.

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