By Jack Ganssle

Productivity

Published 12/23/2004

We're all superprogrammers. Or at least perform in the stratospheric top quartile of developers. Maybe Joe Coder down the hall is "average," but us? We're the tops.

Somehow we make this assessment based on a qualitative "feel" driven more by ego than hard data. Nothing costs more than firmware, yet no other industry manages productivity so poorly. That used car salesman with the crooked teeth and untrustworthy smile watches his sales numbers like a hawk. The widgets we design are manufactured in a facility that tracks defects, rework, worker productivity and more, usually with graphs posted in the halls so everyone knows just how well things are going.

But us? We'll work hard. Real hard. It'll be done when it's done.

Most classical software estimation techniques naively yet wisely expect developers to design the software, decompose it into modules, and then figure the number of lines of code for each module. Then we solve one of the most interesting equations extant:

. when no one has a clue as to the size of the second term. Is it 50 lines/month? 500? 5 million?

At this point the usual chorus waltzes in from stage right to complain that "lines of code" (LOC) is a very poor metric, subject to huge variations depending on styles and more. I'll sing along, too, brother!

Academics, especially, fault the LOC metric and generally advocate some form of function points as a replacement. But, in industry, no one uses functions points, so if I tell you a routine will be 50 FPs you'll have no gut feel for the module's complexity. If, on the other hand, I tell you it's 2500 LOC you'll have that visceral understanding of its complexity. If tomorrow a charismatic leader took over the country and told us all gas mileage calculations will be figured in furlongs per dram, well the numbers will be just as accurate as liters/kilometer or gallons/mile. but will baffle consumers. Familiarity has value.

Oddly, the literature is full of conversions between function points and LOC. On average, across all languages, one FP burns around 100 lines of code. For C++ the number is in the 50s. So the two metrics are, for engineering purposes at least, equivalent.

Sometimes the Function Point debate is merely FUD tossed in to avoid the real issue - that of measuring something, anything to get some kind of assessment into our productivity numbers. There are many ways to measure productivity; two companies I know quite literally monitor network traffic to log keystrokes per hour. Those engineers write a lot of long-winded comments.

Why take such data? If we're lucky enough to have the time to decompose a problem into subunits and LOC before estimating, then the numbers give us a reasonable shot at coming up with a realistic schedule. (For an alternative approach to estimation see "The Middle Way" http://www.embedded.com/showArticle.jhtml?articleID=49901892). Barry Boehm has shown us that the schedule is proportional to the number of thousands of lines of code raised to some exponent. His Constructive Cost Model (COCOMO) gives various exponents and scaling coefficients to predict development time of various kinds of software.

But even when we're just furiously coding to a capricious deadline tracking LOC/hour tells us, when measured over the long term, if we're improving, or just stagnating at our efforts.

This is a whole new world, folks, one that was almost inconceivable just a few years ago. The Wal-Martization of software development means Joe Coder sitting comfortably in downtown San Jose is competing directly with a very smart, highly trained developer a half a world away, thrilled to work for just a fraction of Joe's salary. If we're not constantly becoming more productive we'll be retreads on the grinding wheel of global capitalism.

Track LOC/hour, measuring total time invested from the beginning of the project till the day it's finally done. That encompasses a lot more than coding and debugging. but all of the other development activities are real costs more or less proportional to the size of the project.

Track project size as well. You might crank 200 LOC/month on a 100k LOC project, but your rates will be much higher for smaller systems.

And log bug rates. It's easy to write lots of buggy code fast.

Do you track any sort of programmer productivity figures? Why not?