|
When lines of code meet the Law of Unintended Consequences
By Dustin Marx
One of the most insightful articles that I have read (in terms of both general daily life and a software development career)
is Steven Kerr's "On the Folly of Rewarding A, While Hoping for B." In this article originally published in 1975, Kerr employs
descriptive examples to demonstrate how a reward system can lead to different and even opposite results than intended. Using
lines of code to measure effort and developer productivity often feels like another example of this tendency.
The use of lines of code as a metric may serve as a detrimental motivational force for the software developer. In other words,
while using lines of code may be meant to measure productivity and to understand how far along a particular task is, the unintended
consequence may be poor decisions that favor larger code counts in shorter periods of time.
If we applied Kerr's article directly to this discussion, we might rename the article "On the folly of rewarding potentially
worse development practices that happen to lead to more lines of code, while hoping for a measurement and estimation approach
that helps developers and managers manage their work loads more effectively." This is not nearly as succinct a title as the
original title, but does make the point. To be clear, I am not saying that fewer lines of code is always and necessarily better
than more lines of code. What I am writing about here are situations when it's preferable to write fewer lines of code, but
the motivation to keep that count up influences the decision.
How does using lines of code as a performance metric decrease code quality? Read on to find out.
Also see:
On the Folly of Rewarding A, While Hoping for B (Steven Kerr)
Analyzing code metrics - unambiguously (Andrew Glover, JW Blogs)
More in JW Blogs:
Java.next #3: Dispatch strategies
Stuart Halloway writes: Flexible dispatch is a key element of Java.next. All of the Java.next languages support dispatch strategies
that are far more flexible than Java's single dispatch. These strategies are not perfectly interchangeable, but have a great
degree of overlap ...
Five unit testing tips: #1. Use the data store
Johannes Brodwall writes: I’ve looked over some of my code lately, and found ways that I often improve my tests. I’m planning
on writing a blog post for each of my five favorites. First out: Using the data storage ...
The elephant
Charles Nutter writes: I was just having a conversation with a friend, a Rubyist whose opinion I respect, who clued me in
that he really hates when JRuby users use Java libraries with little or no Ruby syntactic sugar. He hates that there's a better
chance every day that Java-related technologies will enter his world ...
You've hit the tip of the iceberg: Read more in JW Blogs
|
Back to newsletter list
