Lines of code: The best metric to prove you're a clueless exec
A few weeks ago, we published an article advocating the merits of lines of code as a productivity metric for software development after Elon Musk reportedly asked Twitter engineers to present him with their recent work. The response from software developers themselves was... less than stellar. With “a load of garbage” and “offensively stupid” being the tip of the iceberg.
Although we understand that lines of code are sometimes used by some engineers at JPMorgan as a metric to measure productivity, the measure certainly isn't universally favoured in financial services. One senior trading floor engineer says it's more about the "problems that are solved," and the "work that's delivered in reasonable time." Another senior engineer, now at JPM, says lines of code haven't been used to measure developers' productivity "since the 1980s." Right. 🥴
The problem, says Bryan Finster, a distinguished engineer working in the defense industry, is that there simply is “no viable individual productivity measure” on an individual basis.
Finster says lines of code are a particularly egregious example as it suggests companies view their engineers as “typers, rather than engineers,” focusing solely on quantity of output with no thought towards its context. They see as “replaceable cogs” because “code is code is code,” no matter who types it.
Finster notes that “people will always work to and optimize the thing they are measured by,” and in the case of lines of code, this can actively harm productivity.
Traditionally, “senior engineers are leading the direction rather than pounding out code” and so will have comparatively lower numbers to less experienced recruits. If LOC were to be used, those senior engineers would dedicate less time to giving direction to a project or helping greener developers improve and instead just type without an implicit goal.
In fact, churning out lines of code can indicate a lack of productivity. Finster suggests that if there's one high performer in a group of low performers, it suggests they “don’t interact well with the team and can cause internal friction.” Finster says “leadership and involvement with people rather than making decisions is more important” than just writing more code for an engineer in that situation.
This doesn't mean LOC are entirely redundant. Another JPMorgan VP says he looks at Jira tickets closed, lines of code and code commits per engineer, but that they're not used to track people. - They're only really used to identify serious underperformers.
The metrics that are truly effective are less determinative. Finster advises asking questions like “are we delivering what the end user needs in the most efficient way?” One banking engineer says the best measures are subjective and take into consideration the technical difficulty of a project. However, this exposes engineers to managers' biases.
Really, there's no perfect way of measuring developers' productivity. But if you have suggestions we'd like to know in the comments box below.
Have a confidential story, tip, or comment you’d like to share? Contact: alex.mcmurray@efinancialcareers.com in the first instance.
Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)
Photo credit: eFinancialCareers/Dall-e
