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

It depends a lot on Personality

[epeus]

Fortunately, you can tell a programmer's personality type by the code they write - it is all explained in this paper by Kevin Marks & Maf Vosburgh

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

Ancient issue has been addressed before

[GMontag]

Ummm, this appears to be a regurgitation of a segment from Triumph of the Nerds . With the Microsoft guys saying that productivity should be based on getting a problem solved vs. the IBM guys saying that productivity should be based on LOC or KLOC (thousands of lines of code) or MLOC (millions) etc.

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.

The Mythical Man-Month

[Animats]

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