[ #24 ] Gauging Developer Progress Permalink

Rant, Agile Added nearly two years ago

Here's a ridiculous article that attempts to espouse the benefits of counting lines of code (LOC) by comparing software development to house building: Counting lines of code can help measure progress

Development is often compared to building a house. I’ve built a house, and I can tell you that while I did want the bricklayers to be finished on time, that wasn't enough to satisfy me when I had to write the check. Generally, I’d check their progress every day, and I would notice how much brick had been laid.

What this moron and his ilk fail to understand is that software engineering is a different style of work to ... well, anything. Let's take his building example. A house, 99% of the time, is a solved problem. A builder who has worked on previous houses already knows exactly how to build the next house (unless it's a fancy architectural-type house, or it's built on sand or made entirely from glass etc.) In software development however, if a large problem has already been solved before then that module (or open source library) can be reused. Therefore new work being done by devs often (not always) fits into one of these categories:

... and this work can be equally or more important than new features written from scratch. It can also be less important - it all depends on the value of the features, not on the lines of code it takes to write them.

Both refactoring and bug-fixing can sometimes actually reduce the number of LOC in an application, because existing code is studied for any inefficiencies or errors and newer, simpler, more modular, more elegant code replaces it. If you were measuring LOC based on changed lines then this would be taken into account, but if you are measuring LOC based on new lines then this work would be ignored. Let's say we were indeed taking into account changed lines, and we have an example where 5 lines were altered and 3 lines removed to give an efficiency increase of 300%. Should these 8 line-changes be given equal weight to 100 lines of code elsewhere that only adds one small feature? You would have to compare the value of the small feature to the value of the efficiency increase!

Compare ticket values, not lines of code written.

Sometimes a bug can be so insidious that it can take a whole day to find and fix - and it might be a one-line fix. Should a developer be punished for this, just because his daily LOC measurement is low? What if the bug-fix was a show-stopper? Even our old friend William Gates thinks that would be a bad idea:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

**Scrum** takes care of the problem by examining relative complexity values during sprint planning meetings. Once a list of tickets (items to be worked on) have complexity values you can estimate their development time and equally distribute the tickets among developers. Progress assessment is now easy, managers just need to check the burn-down charts... and that eliminates the need for misguided and archaic measurement techniques like LOC checks.

Colophon

Django Python 960.gs Git Vim NetBSD Nginx

The Author

This is the blog of Brad Willis, a software engineer living in Brisbane.

Meta

Help
Latest entries

*BSD Agile Apache Apple apt Athletics Best-Practice Censorship Comedy Cool Crosswords Deployment Django English Exim Firefox Git Hardcore Health irssi Javascript Jira Languages Linux Makefile Mathematics Mobile Broadband Mutt MySQL NetBSD nginx Nokia OpenVZ OSX Perl Privacy Python Rant Requirements rsync Ruby Shell Slackware SQL SQLite SSH Standards Subversion Television Testing ThisBlog Vim VMWare (Fusion) VPN X zsh

Recent Entries

Checking for exceptions in doctests
Homer's Curling Speech
retry in Python
Vim Makefile tabs
Centos (or RH) IPTables
Converting ssh2 public keys to openssh
Vim comment hints
Context managers in Perl
Dish rotation
Git - fixing commit user
apt stuff
Using shell variables in AWK
Linux - Too many open files
Tell gvim to save and quit... remotely
Vim - automatically remove whitespace at EOL
Python - relative paths from within modules
TV Aspect Ratios
Git - Which commits are in your branch only?
Subversion setup cheat sheet
Force detach a screen session
Modify sudo's use of environment variables
Install all Perl modules
Mutt - delete old messages
OpenVZ VPS and swap space
fail2ban on NetBSD for ssh
NetBSD - Using sup
Python - testing for a sys.exit
Python Best Practice Link Dump
Python script names
Perl - Using an expensive module
Speed of git clone
Perl Modules with Custom Prefix
Perl: tr vs. s
Brilliant sysadmin Reference
Why is GRUB better than LILO?
Why is swap space important?
Perldoc Output
Git's Index
Jira Project Keys
Git GUI

Links

ChoppingBoard, DaveMisc, Project365, RageQuit