[ic] Programming Metrics (Was: Akopia in PHP)

[Doug Alcorn]

IC-Admin <interchange@my-school.com> writes:

> The reason I am asking is because (being obviously not a programmer
> and only lurking here out of being an old loyal fan of Minivend)
> some people have tried to ridicule me in the past in private email
> of "defending" Minivend and Mike Heins in the past. I felt somewhat
> angry about it and helpless, because I had no comparison to other
> developer's achievements and could never judge it. Luckily now as
> the code is under RedHat's umbrella, I feel a little bit better, as
> my judgement was obviously not so bad. But I don't forget those guys
> who tried to ridicule me. May be someone likes to answer that
> one. It's so hard for a non programmer to judge a program and a
> programmer.

This is a difficult subject.  You would think for as long as
programmers have been working there would be good numbers on how long
it takes to write X number of lines of code.  Unfotunately there
aren't good numbers.  

I think the problem is that it's not linear.  Sure, I can pretty
accurately estimate jobs that are 20 hours or less.  I can somewhat
accurately estimate jobs that are up to 50 hours.  Jobs that are more
than 100 hours of work are just shots in the dark.  But that's
forecasting not measurements.  Weather workst the same way.
Meteorologists can accurately predict weather for the next 24 hours or
so, but you hardly ever see 14 day forecasts.

The problem is unforeseen complexity.  You can break a job up into
small, easily understood components and then add up all the small
estimates.  That's a fairly typical approach.  You say, "to accomplish
big project A I need to finish small projects B, C, and D.  Since I
know how long B, C, and D should take then A should take X hours."
But what always happens is that you finish B and C, but now that you
actually tackle D you see that B and C won't do at all.  So you have
to paritally or totally re-write B and C.

As far as hind-site goes, I don't really think think there is a
"code-per-day" number that is generally applicable.  Elsewhere in this
thread, Mike said it took him 5 years to write minivend with some help
from others.  That's a long time, but doesn't seem unreasonable for
the power and flexibility of Interchagne.

To summarize, I don't think lines-per-day is a good metric.  It is
seductively appealing because it is so quantitative.  The problem
again is complexity.  Some features can be expressed in a small number
of lines (even if they are complex).  The other problem is that
tasks/features are different by class.  Server code is traditionally
more dense than GUI code.

I think what you have to do is look at the scope of the problem.  How
large is the problem space and how much of it is covered by the
application? Also developing applications is easier than developing
libraries which is easier than developing frameworks.  And then
there's one of my favorite quotes, "You can have it either fast, good,
or cheap; choose any two."
-- 
 (__) Doug Alcorn (mailto:doug@lathi.net http://www.lathi.net)
 oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
 |_/  If you're a capitalist and you have the best goods and they're
      free, you don't have to proselytize, you just have to wait.