Measuring Programmer Productivity
Software "metrics" have been a hot topic for decades, chiefly, I think, because it has frustrated managers who were used to managing assembly line workers or salesmen, whose output they could easily gauge, and for whom it was easy to tell if they were working or not, to have to manage programmers. With the latter, "working" very well could consist in staring dreamily off into space for an hour, and it was very hard to guess if the pieces being assembled would ever compose a working product. (As the old joke goes, all software projects rapidly reach 95% completion, and then stay that way forever.)
But the worst proposed way to measure productivity of which I am aware is by lines of code. Reaching for a comparably poor way to measure productivity, I come up with measuring a basketball players productivity by how long they spend holding the ball. Or perhaps even better, measuring a golfer's productivity... by the number of shots they take in a round.
I found a bug in a program last night. I wasn't sure what was causing it, so I went to bed. I woke up in the morning and immediately knew the source of the bug. (This happens to me often: I once popped awake at 3 AM and exclaimed "I have to increment x after the loop, not before it!") But how to fix it was a more delicate matter, reaching into the fundamental design of the system. So I texted my main program design consultant, and he responded "Call me now." We talked for twenty minutes, and I knew just what to do.
I sat down at the computer, deleted one line of code, and copied another into its place. The change literally took about three seconds, and produced zero new lines of code. By the lines-of-code metric, I had been completely unproductive since I had quit for the evening last night. By contrast, a naive programmer who immediately began coding to "fix" the problem might have written dozens of lines of unnecessary code to set things right.
As with golf, the goal should be to get the ball in the whole in the fewest (key)strokes possible, not the most!
But the worst proposed way to measure productivity of which I am aware is by lines of code. Reaching for a comparably poor way to measure productivity, I come up with measuring a basketball players productivity by how long they spend holding the ball. Or perhaps even better, measuring a golfer's productivity... by the number of shots they take in a round.
I found a bug in a program last night. I wasn't sure what was causing it, so I went to bed. I woke up in the morning and immediately knew the source of the bug. (This happens to me often: I once popped awake at 3 AM and exclaimed "I have to increment x after the loop, not before it!") But how to fix it was a more delicate matter, reaching into the fundamental design of the system. So I texted my main program design consultant, and he responded "Call me now." We talked for twenty minutes, and I knew just what to do.
I sat down at the computer, deleted one line of code, and copied another into its place. The change literally took about three seconds, and produced zero new lines of code. By the lines-of-code metric, I had been completely unproductive since I had quit for the evening last night. By contrast, a naive programmer who immediately began coding to "fix" the problem might have written dozens of lines of unnecessary code to set things right.
As with golf, the goal should be to get the ball in the whole in the fewest (key)strokes possible, not the most!
Indeed. My greatest productivity usually comes from what I don't do. I fixed a program tha crippled a mainframe for 48 hours, by figuring out how to get better results with hugely less work. Software is not an assembly line.
ReplyDeleteThere are no sensible metrics in this area, and yet increasingly we are driven by them. For two years our developers have had daily meetings on them as our project headed over a cliff. No-one believed the few of us raising warnings. They had their metrics, all we had was our judgment. Then one day, boom.
"Rationalism in coding": it can all be reduced to a system, with no judgment necessary.
DeleteEven after sixty years of software development, many organizations appear to have a 'bricklayer' model of software development. This implies of course counting how many bricks a developer has laid. It also encompasses the odd idea than an architect or a business analyst will write a spec, and that a developer will 'code it up', as if a requirements document is some kind of blueprint and a developer is simply building the concrete representation. To state the obvious, the *source code* is the blueprint, and the software builds itself!
ReplyDeleteA much better metaphor is gardening. The proper role of the development management is to ensure the prerequisites are in place, to choose the appropriate varieties for the available soil, and to prune and weed as required. He also has to appreciate that it takes time for things to grow.
To deliberately mix metaphors: if a mature oak is wanted, many project managers hire an architect to draw a model of an oak tree, estimate how many bricks are required to build an oak tree of that size, then hire sufficient bricklayers at the lowest cost location to build the oak tree. Progress is often good on the trunk, but slows towards the fine branches. Needless to say, the client is ultimately disappointed.