Why Lines of Code (LOC) Measures Irritate Me
From the pmStudent Blog
by Josh Nankivel
Ranting and raving about project management and systems engineering.
Recent Posts
The Problem with Project Management
The Problem with Project Management
The Problem with Project Management
LinkedIn Recommendations Are Easy
The Catch-22 of Project Management Certification and Experience
Categories
Agile,
Career Development,
Certification,
Change Management,
Communications Management,
Cost Management,
Documentation,
Earned Value Management,
Education,
Integration and Test,
Kanban,
Leadership,
Lean,
Lessons Learned,
Methodology,
Misc,
Multitasking,
New Project,
Operations,
Planning,
PMP,
Productivity,
Professional Development,
Project Estimation,
Project Leadership,
Quality,
Requirements Management,
Risk Management,
Schedule Management,
Scope Management,
Software,
Systems Thinking,
Tools,
Video,
Work Breakdown Structures (WBS)
Date
If you've done any work in systems or software development, you've probably use Lines of Code (LOC) before.
Either as an estimation tool with something like COCOMO, or as a retrospective gauge of the work your team did on a particular release of software with added/modified lines of code.
It's All Bull
Lines of Code as a measure of productivity or as an estimation tool is nearly meaningless. But it's something quantifyable and so people (especially managers) grab hold of it like a life raft.
I feel very similarly about Function Points, and I think both of these try to simplify something that is too complex for a one-size-fits-all method.
Here's the problem with equating LOC with productivity, effort, or estimates:
-
An engineer may spend several hours on a block of code less than 20 lines, and the next day spend the same amount of time on writing 1000 lines of new code. Both are completely valid, and reality. It's all a matter of context.
-
A system with 50k LOC that does the same thing as another system with 100k LOC is twice as good as the 100k LOC system, I'd argue. The lower LOC system is refactored better, less complexity for the same functionality, and easier to maintain.
-
I re-wrote about 40 lines of code a few weeks ago (this is rare, I usually don't do much programming any more) because of a performance issue. The end result was half the code, and a roughly 450x improvement in performance (returning records in 400ms from a database instead of the ~3 minutes it was taking). I spent an hour reducing LOC to improve the system.
Now tell me how LOC can possibly be a global proxy for value or productivity?
User Stories or Features
I think the best proxy we have is user stories or features completed, provided and assuming they are valid. It's really just as valid a measure as any other arena like construction...you have assumptions that requirements were elicited properly and you are actually building what the customer wants.
What do you think? How do you measure or estimate productivity/effort on your software projects?
Posted on: February 29, 2012 06:59 PM |
Permalink
Comments (5)
Please login or join to subscribe to this item
Geoff Crane
Owner| Adaptimist Insights
Peterborough, Ontario, Canada
OMG Josh, hear hear! As far as I'm concerned, LOC is a worthless measure and completely sends the wrong message to stakeholders. LOC is a measure more akin to digging holes and filling them in just to appear busy.
Ultimately what matters are the results that the code delivers to the business. The way I dealt with this was to force my staff, on a weekly basis, to summarize for me the new value their code created. For example, instead of telling me "we wrote x lines of code and installed a [insert jargony name of server patch here]", tell me, "our investment bank customers can now trade economic derivatives because of our work, risk management no longer has to wait for their reports to finish in the morning and we've fixed the blank accounting entries that were showing up in the general ledger".
Those are measures that have meaning, and I can take that right to my customers and say "here's what we did for you this month". With language like that, I could move away from function points and LOC, and easily defend my division's right to exist. And isn't that the point of measurements in the first place?
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
You said it Geoff. VALUE. That's the only thing that really matters.
Hi Josh ,
Thanks for coming up with such an useful article .
I have found the LOC technique to be a useful tool in maintenance projects which are similar in nature However , I agree with you that it cannot be effectively used as a tool for estimating productivity / effort on our software projects. I can write less code and come up with an application which has greater value .For instance by using Microsoft Enterprise Library effectively , I can reduce my workload and yet satisfy the common application concerns .
In most software application development projects , I am compelled to use multiple estimation techniques including top to bottom approach and bottom to top approaches to be closer to the actual figures.My experience in handling similar projects also helps me in my estimations .
For instance , my experience in handling POC development for a particular application in healthcare domain , helps me in estimating the time , cost and resources required to complete the design , coding and testing of many similar projects in the same domain .
I have also found the bottom to top approach to be quite accurate in scenarios where I have enough details about the project . But in majority of the projects, where we do not have enough details , the top to bottom approach works well .
I have also found that by using 2-3 estimation techniques and comparing them can help us in deriving estimates that are closer to the actual figures .
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Thanks for the comment Sabyasachi!
It's a good point about a rough ability to judge large differences in size, especially when the environment is stable. LOC can definitely be an input to the estimation of maintenance effort. The more LOC in general, the more maintenance required all other factors being equal.
Mike Walls
IT Strategy Manager| City of Richmond Dept. of Information Technology
Richmond, Va, United States
LOC is a terrible measure of performance, though as Sabyasachi Gupta notes it has some value as measure of effort when working with an existing code base. Function point can be better, if functionality is carefully and consistently defined -- though one function may wind up taking 5 times as long as another (and only a tenth the number of lines of code).
Back when I coded regularly, I adopted a standardized line break and indentation style that added a lot of white space to my source code. But, it made finding problems with loops, span of control, etc. much easier. It also made my code highly readable and thus maintainable. (I got the approach from a now-forgotten tool that helped automate James Martin''s action diagramming technique, for those interested.) For example, in C I would indent one unit for the opening bracket of a code block, put all the lines of code at the same level, and put the closing brace on a separate line, then outdent one level for the next statement.
This approach added significantly to my LOC count, but didn''t necessarily make me more productive than someone who compressed their source code onto a few dense lines. However, the maintenance coders much preferred my style.
In my experience, the only reliable way of estimating effort is through having an experienced developer who thoroughly understands the problem space make the estimate. But, then you have to factor in the skill/experience of the available programmer -- I may be able to knock out a SQL query in a day that the assigned junior programmer might need a week for.
Hey, if this stuff was easy, they wouldn''t pay us the big bucks!
Please Login/Register to leave a comment.
|
"Life is like music; it must be composed by ear, feeling, and instinct, not by rule."
- Samuel Butler
|
