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...
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.
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!)
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.
