Slashdot Mirror
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.
Phew, what a long winded way to say: KLOC 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. ;-)
If you were blocking sigs, you wouldn't have to read this.
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.
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 like commentParserDatabaseCursor. I also like i, j, p, and retval. The length of an identifier should be roughly proportional to the log of the size of its scope. A file scope "i" is an abomination. A loop scope "commentParserDatabaseCursor" is an idiocy.
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!
The firm I'm working for hired a contractor to write the system software for their scientific instrument.
... other conditional code // to exit
...
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.
Coming soon - pyrogyra