Articles...

Copyright 2009 Corvus International Inc.  All Rights Reserved

Home      About Corvus       Contact Us       Articles/Resources       Clients          Affiliations  

Beware of counting LOC, my son!

The code you write, online or batch

Beware the public word and shun

The voluminous standard patch!


                   
Java-Wocky?                   

               ...with apologies to Lewis Carroll

 


ACM DL Author-ize serviceBeware of counting LOC

Phillip G. Armour
Communications of the ACM - Homeland security, 2004


Counting Lines of Code (LOC)?  You kidding me?  In this day and age, to be counting up command lines of a 3GL to size a system seems old fashioned, if not plain weird.  Lines of Code are soooo 1980s COBOL...

But how would we otherwise size a system?  If we use Function Points (FP) in one of their many guises, we often resort to "backfiring" into LOC.  Ditto with other measures.  But why this obsession, first with "sizing" a system and secondly with sizing it in LOC?  I mean, who cares how "big" a system is?

That's What the Tools Use                                                   


The primary purpose of sizing in LOC is to be able to use one of the available estimation tools.  All major tools: QSM's SLIM-Estimate, Galorath's SEER-SEM, CostXPert, COCOMO (I or II, your choice), Softstar Systems' Costar, SPR's KnowledgePLAN, or pretty any other I've ever used or heard* of drive the estimate primarily from the size of the delivered system.  And guess what unit the size used by all these tools is measured in?

Right.  Lines of Code

The Basic Equation                                                               


The basic equation for converting a "size" to an effort is:

EFFORT = a * SIZEb

Where a and b are "constants" (not really, but I kept it simple for this article).  Typical values for a and b are:

a = 2.94
b = 1.1

most of the tools are also able to convert the effort into a putative schedule.  A typical formula for this is:

SCHEDULE = c * EFFORTd

where c and d are also "constants" that have typical values of:

c  = 3.0
d = 0.33

Ideally, we would calculate the empirical values of these constants from historical project data.

Why LOC?                                                                           


Why is LOC the base unit for all of these tools?  The answer is simple:

We Actually Measure the Substrate                                   


All of our system size metrics do not measure the system "size" they measure the amount of space the system knowledge would take up in one particular form.  They measure the "substrate" on which the system knowledge is placed.  Then we make the assumption that the amount of space the system knowledge takes up is proportional to the amount of knowledge in the system (which is proportional to the amount of knowledge we have to get, which is what takes the effort and time).

But it Doesn't Matter That Much Anyway...                           


In a later article, I will show why your choice of system sizing metric is not nearly as important you might think it should be.

* Not all "estimation tools" use LOC.  There are some tools and approaches that go straight to an effort, without calculating the effort-schedule relationship.  This is a tad dangerous, since without an associated schedule, we are tempted to simply divide the effort by a larger number of people to reduce the schedule.  Unfortunately, we cannot build a 10,000 Staff Hour system in one hour using 10,000 people.  As Fred Brooks observed: the bearing of a child is a nine-woman month job, but we cannot do it in one month using nine women

Beware of Counting LOC