The Easiest Developer Productivity Measure of All - Not!

It's 2019 and I can't believe I'm in this position again. I ran across an organization that was trying to find a way to measure the productivity of a team of developers. Their insistence on using lines-of-code (LOC) brought back some long-suppressed PTSD from years ago. Before diving into that subject, let's take a minute to get an orientation around the problems of using productivity performance metrics, as espoused in "Against metrics: how measuring performance by number backfires".

It's only a five-minute read. I'll wait...

https://aeon.co/ideas/against-metrics-how-measuring-performance-by-numbers-backfires?utm_source=hackernewsletter&utm_medium=email&utm_term=fav

Hopefully your unease has increased. So, let's get right into it.

LOC was probably the earliest attempt at measuring developer productivity. The concept was simple and was borrowed from operations research in the domain of a factory production. In such a setting, you might try to measure the productivity of an assembly line worker by counting how many widgets they processed - and that output widget pile just keeps on growing - go, team.

It's a simple hop to apply this in the software world. Developers produce value by writing code. The more the better. A developer who writes a lot of code is clearly better than a developer who writes less code.

If you are trying to measure a developer's or team's bottom line dollar impact to business, and you are looking covetously at LOC, then let me try to talk you down off that ledge by asking some questions.

* What do you want to use this productivity measure for?

* Are you trying to compare the delivered value among individual developers?

* Are you comparing delivered value of different teams?

* Are you deciding if a project delivered enough value to the business

You can see from the abstract reference to value in the above questions that LOC as a productivity is not a good fit. The LOC metric is very, very narrow and has the following false-isms (and with a few minutes more thought, this list can be increased).

* Non-coding tasks have no value

* Reducing risk via spikes has no value

* Design and architecture discussions have no value

* Concise coding has less value

* Taking more time and getting fewer bugs has less value

* Writing internal documentation has no value

* Performance testing has no value

As alluded to in the cited "backfire" article, your organization may morph under the pressure of productivity measures. Specifically, developers will gravitate to having "higher productivity" aka more LOC, so be careful what you incentivize. The absurdity of the situation is captured nicely in one of my all-time favorite Dilbert cartoons. (Yes, you can get this on a mug to carry your coffee around every workday!)

https://dilbert.com/strip/1995-11-13

So, you still insist on using LOC as a metric?

Let's look more closely at the code. What lines do we want to count? Configuration lines like Xml? What if those XML lines actually replace code as in the case of dependency injection? Data files like JSON? What if this is a declarative representation to replace ad hoc coding? Generated code? Should you be counting the sources of this generation instead? So you can see that the definition of what is code has moved beyond the traditional, simplistic definition.

Is a line-of-code a LOC?

Do comments have any value? Ha, ha, ya, it is a trick question. What about comparing across languages? A given bit of logic can be expressed concisely in some languages and more verbosely in others, so how does that affect things? What about lines of test code versus lines of production code? What about test code density? (Spock/Groovy is about 5 times denser than JUnit/Java)

How do you account for the lifespan of a LOC?

Refactoring can result in negative productivity. One of my long-time assertions is that one of the most valuable things a developer can do is to throw away code. An example of this would be when a developer reduces the damage of "copy-paste-itis" and coalesces to a function. That is going to reduce testing and maintenance costs. Also how do you handle splitting/merging of repositories? The effect of this can be very difficult to track against LOC metrics.

What about other measures?

In an agile environment, the team is refocused on the moving "business value" target at the start of each sprint. The sprint stories were vetted by the product owner, who should have marketing's estimated value of each feature. This is a very direct way to assess value. So what if you don't have access to that? Well, you could use the "T-Shirt Sizing" estimates as an abstract measure. If that isn't available, you might use stories/iteration or points/iteration, with the caution that the definition of a point will vary among teams.

Other Resources

You can find Martin Fowler's take on using LOC here... https://martinfowler.com/bliki/CannotMeasureProductivity.html

There is a good article on agile metrics for productivity here... https://www.business.com/articles/agile-team-productivity-metrics/

That's it for now - hopefully you are no longer on that ledge.