Project Management

pmStudent

by
Ranting and raving about project management and systems engineering.

About this Blog

RSS

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

Why Lines of Code (LOC) Measures Irritate Me

Categories: Software

linkedin twitter facebook Request to reuse this  

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)
ADVERTISEMENTS

"I am not young enough to know everything."

- Oscar Wilde

ADVERTISEMENT

Sponsors