When it comes to programmer productivity one metric, widely used in times past, is lines of code produced. Since code is one of the more visible outputs of a programmer it seems reasonable, at least on the surface, to use this as a gauge of how much work these people you’re paying lots of money to are doing.
The problem with this is that it puts the metric on the wrong side of the accounting ledger. One of the surest ways to improve the quality of software is to write less of it. This seems counterintuitive but it’s a natural corollary of the concept of reuse.
It’s a familiar principle in pretty much every other area of modern life. We don’t expect construction workers to produce their own vegetables, raise their own cattle, sew their own clothes, make their own mattresses, etc… because it’s much more efficient for them to focus on construction work and purchase those necessities from people that specialize in producing them. That is, the construction worker does a better job focusing on construction and gets a better mattress from the mattress maker than if he tried to do both. The mattress maker needs a place to make mattresses and gets a better quality building if he lets the construction worker build it.
The analogue in software is the use of libraries. Of course not all libraries are created equal but if you’ve got a choice between using something that’s been specifically built for a purpose that is largely ancillary to your own purpose then you can reap major efficiency gains by taking advantage of it.
The sorting library that has every kind of sort from merge sort to quick sort to postman’s sort has probably done a much better job at implementing the sorts than you have time to replicate. Especially if sorting is only a small part of the total piece of functionality someone is paying you to produce.
When considered in that light, the phrase “lines of code produced” seems incongruous. It should be, to borrow a phrase from Dijkstra, “Lines of code spent” and accounted for as a cost.