[lug] can't make this stuff up, folks... My 2 lines of code, errr, I mean, my 2 cents....

[Rob Nagler]

On 10/20/09, Bear Giles wrote:
> Here's today fun question: does "lines of code per day" include test code?
> I know some people who claim that you should spend at least an hour writing
> tests for every hour you spend writing code.  Ideally closer to a 2:1 ratio.

I find that it takes much longer to create the test data and structure
than to write the code.  I've never timed it, though.  If I'm just
hacking something together ("spike" in XP parlance), I spend almost no
time on testing.  If I'm working on importing accounting from OFX
servers, test data are extremely important.

I have an incredibly hard time with measuring productivity, in LOC or
otherwise.  Most of our applications are about 10-20K NCLOC.
Applications written by other companies which do similar things often
run into the 100Ks if not millions, and often involve scores of
programmers.  bOP itself is about 60K NCLOC, and that's including the
PetShop application.  When we wrote the PetShop application, we were
"competing" with J2EE's Pet Store, which had 10x LOC, and was a
copy-and-paste nightmare.

Producing lines of code or tests is not necessarily productive.  Being at
your keyboard is necessary but doesn't actually tell you anything about
your productivity.  The only way to compare productivity to my mind is
to compare ROI between two equivalent projects.  And even then, you
have to define what you consider ROI.  For many of our customers, ROI
is not measured in dollars, because the projects are internal.  They
have to satisfy their customers within a certain budget.  In at least
one case, one of our customers hired us just as they were about to
lose one of their biggest customers due to a failure at RackSpace
which couldn't be recovered by RackSpace or by the people maintaining
the system.  The site was down for over 24 hours, and was only pieced
back together from software and data on various computers.  The
situation was binary for our customer.  Since switching, they haven't
had that problem any more.  Yet, it could happen.  If it does happen,
then our ROI is negative.  If it doesn't happen, my customer and their
customers are happy, and ROI is quite positive.

Think about the Y2K thing.  A bunch of programmers sat in a room and
coded.  After they got done, people might have measured their
productivity.  Yet, the cost of the Y2K fix might have dwarfed the
original development cost, because there were no tests and the
source code might have been lost.

So the question I ask myself: What's the value to the customer of what
I produced today, and have I mitigated the known and unknown risks?
That's a very tough standard, but I see no point in asking any other.
Do you?

Rob