It amazes me that in 2016, I still hear the occasional story of some software team manager measuring developer productivity by committed lines of code (LOC) per day. In fact, this reminds me of hearing about measles outbreaks. That this still takes place shocks and creates an intense sense of anachronism.
I don’t have an original source, but Bill Gates is reputed to have offered pithy insight on this topic. “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” This cuts right to the point that “more and faster” does not equal “fit for purpose.” You can write an awful lot of code without any of it proving useful.
Before heading too far down the management criticism rabbit hole, let’s pull back a bit. Let’s take a look at why LOC represents such an attractive nuisance for management.
For many managers, years have passed since their days of slinging code (if those days ever existed in the first place). So this puts them in the unenviable position of managing something relatively opaque to them. And opacity runs afoul of the standard management playbook, wherein they take responsibility for evaluating performances, forecasting, and establishing metric-based incentives.
The Attraction of Lines of Code
Let’s consider a study in contrasts. Imagine that you took a job managing a team of ditch diggers. Each day you could stand there with your clipboard, evaluating visible progress and performance. The diggers that moved the most dirt per hour would represent your superstars and the ones that tired easily and took many breaks would represent the laggards. You could forecast milestones by observing yards dug per day and then extrapolating that over the course of days, weeks, and months. Your reports up to your superiors practically write themselves.
But now let’s change the game a bit. Imagine that all ditches were dug purely underground and that you had to remain on the surface at all times. Suddenly accounts or progress, metrics, and performance all come indirectly. You need to rely on anecdotes from your team about one another to understand performance. And you only know whether or not you’ve hit a milestone on the day that water either starts draining or stays where it is.
If you found yourself in this position suddenly, wouldn’t you cling to any semblance of measurability as if it were a life preserver? Even if you knew it was reductionist, wouldn’t you cling? Even if you knew it might mislead you? Such is the plight of the dev manager.
In their world of opacity, lines of code represents something concrete and tangible. It offers the promise of making their job substantially more approachable. And so in order to take it away, we need to offer them something else instead.