Re: Estimating projects (was AS/400 Gasping For Air ??)

Simon,

With the depth of your quotables, I had to catch by breath!
But now that I have a second wind, hang on ... this is gonna be a long one ;-)

Now I was taught to always leave things on an up note, so here goes:  (starting 
on the down note) Real question
... what's the demand for assembler/PL1 and do 30 year old statistics apply 
today.  The LOC quoted was under a 80
column card/batch world where today one can "punch" into an active editor.

BTW, my first language was Fortran IV on a S/360 and IMHO the old yard stick no 
longer applies.  I would not
estimate projects today on a 1968 productivity level.

Now the up side.  I agree to the importance of design and hold the adage that 
each hour of design (thought) saves
two in programming (or rework due to lack of forethought).

Upon reflection, each time my company has scratch developed a new application 
for the technology du jour, we did
rework the whole thing in a year (or three installs ... whichever came first).  
Nothing like hindsight! ;-)  Sort
of like Linux is Unix upon reflection or Java is C upon reflection.


> <<snip>>
>
> You are correct that most of the project time goes in design and testing.  My 
>percentages are: 40% design,
> 45% testing, and 15% coding. (I tend to be a bit particular about design.)

In our world a part of that 45% testing is "live" test.  A certain amount of 
time is spent in making sure that if
one follows the rules, and breaks a few, the application does not break.  At 
that point it's put into production
as a "beta".  The fire stomping starts here.  Now don't say you or the 
company's you've worked for doesn't do
this.  It's the test technique of choice for many.

>
>
> Brooks (see below) uses a 1/3 for design, 1/6 for coding, 1/4 for component 
>test, and 1/4 for systems test.
>
> Regardless of how much of the design, and documentation for the original 
>system still exists it will not be
> rewritten in 9 months.  Besides, what would be the point in simply redoing 
>the old system?  Shouldn't you
> take advantage of the exercise and re-design some of it?  I would bet the 
>users would like things done
> differently if they had a chance.

I'm thinking that you may have misspoke in the above, or you may be telling the 
horrible truth, but our
experience is that under a new design/programming paradigm (like going from 
s/34 to s/38 or procedural to OO) the
first 9 months is a trial/trowaway/learning experience.  It's not a keeper.

>
>
> Some figures to substantiate my earlier comments.  These come from "The 
>Mythical Man Month" by
> Frederick P. Brooks.  Note that the best case is 10 KLOC/man-year.  If you 
>are interested I'll try and dig up
> some figures for OO projects for comparison -- although OO projects usually 
>don't show a great return on the
> first foray, the benfits come later once some experience is gained and 
>classes exist to reuse.

True, there is a greater effort without tangible result (user functions) while 
laying the foundation, but once
you have that phase done, the building is pleasantly swift.

>
>
> "A programming systems product takes about nine times as much effort as the 
>component programs written
> separately for private use.  I estimate that productizing (sic - with 
>apologies to Paul M. who will be
> equally offended by that word) imposes a factor of three; and that designing, 
>integrating, and testing
> components into a coherent system imposes a factor of three; and that these 
>costs are essentially independent
> of each other."

The rule of thumb, 25 words or less, I had hammered into me was: It takes 7 
times a long to develop a general
purpose utility then it does to develop a specific purpose function.  Now I'm 
not sure if that fits into your
quote of component building and component binding into a usable application, 
but I have to assume that the
components (if usable) have to be general purpose utilities.  They either 
become components of a greater whole,
or they would be stand alone functions.  Maybe I should up my bids to a factor 
of 9 instead of 7 .... I've short
changed myself ;-)

>
>
> "Data for building isolated small systems are not applicable to programming 
>systems projects."

You lost me on that one.  How about throwing it back within context?

>
>
> "Aron's IBM data show productivity varying from 1.5 KLOC to 10 KLOC/man-year 
>as a function of the number of
> interactions among system parts."

The higher gains may be the rule under OO.  IMHO, LOC does not apply when 
application creation becomes an
assembly of parts.  Parts assembly can no longer use LOC as a yard stick.  Sort 
of like when IBM went from
relative performance to CPW and a B35 (Ya, that's a B) owner looking to upgrade 
asks  "What's the relative
performance of a 170?"

>
>
> "Harr's Bell Labs data show productivities on operating system type work to 
>run about 0.6 KLOC/man-year and
> on compiler type work about 2.2 KLOC for finished products."
>
> "Brooks' OS/360 data agrees with Harr's: 0.6-0.8 KLOC/man-year on operating 
>systems and 2-3 KLOC/man-year on
> compilers.

Just curious, with the open source concept, is there any guess on the man-year 
LOC for Linux?  I would dare to
guess that many members on this list were not born when the 360 was "all 
encompassing" and OO was not a
development concept. 600 LOC/year seems like a long caffeine crazed weekend.

>
>
> "Carbato's MIT Multics data show productivity of 1.2 KLOC/man-year on a mix 
>of operating system and
> compilers, but these are PL/1 LOC, whereas all the other data are assembler."
>
> "Programmer productivity may be increased as much as 5 times when suitable 
>high level language is used."

I take it that the last two quotes are within the same context so one could 
conclude that 6K LOC/man-year is the
"norm" under a HLL.  Now I've a measurable for RPG development LOC/man-year, my 
question would be: How does one
translate yesterday's yardsticks into today's methods? BTW, 50K LOC/man-year is 
not abnormal, actually it's
anemic.

Now I'm talking scratch development, not maintenance.  Janitorial work has a 
substantially lower LOC/man-year.

Case at point: With some home grown tools, my company cranked out 500k LOC for 
a MAPICS competitor in 3 man-years
and placed the product in 70 installations in 4 years.  The first year required 
a revisit to 10% of the code.
Nowadays that would have been called "beta" code.  The first year of 
installation resulted in cosmetic
"upgrades", under the cover standardization and minor bug fixes to justify the 
maintenance fee.  Later we
discontinued the fee because it forced change for change sake

I am not trying to be contrary to your point of view, actually I concur within 
the scope you represent.  As an
estimating factor we would add for each additional person on the project for 
team communication.   Therefore the
larger the team the lower the LOC/man-year  If I recall from earlier posts, 
3000 humans on a project such as
OS/400 was not out of line under the LOC formulas you bring forth.  And having 
done a stint of compiler writing
it's a whole different world than application development.

I'm not sure that some of the quotes you presented are applicable to this 
group.  Maybe I'm in the wrong room,
but I don't think that many of us write compilers or OS's.  I've always had the 
feeling that the majority of this
list have the more mundane task of booking orders or satisfying the latest whim 
of the IRS.

We may actually fall into the statistical realm of spending 70% of our time 
doing maintenance work instead of new
development and that may skew the LOC/man-year numbers.  By that I mean that if 
one were to take a poll of this
group and divide total LOC for 1998 by number of bodies I'm not sure one could 
get a realistic number for new
application development.  One could get a departmental rate, but not a 
dedicated to development individual/team
rate.

Now I may a dirty capitalist pig, but if a person assigned nothing but new 
development isn't cranking out 200
lines of quality code for 200 days of the year, I'd have to give them a pink 
slip.  I'd give myself one!  A
Payroll application is at least 50K LOC and it should be in beta within 160 
man-days producing pay checks and
within the next 80 man-days the end of quarter/year processing should be ready 
for preliminary run.  Having said
all of that I will add one item: the designer has a firm grasp on both the 
requirements of the application and
the capabilities of the platform.  The designer/documentor is 50% of the time 
stated.  The designer either
creates or outsources the creation of all test data including intentional 
failures.

I believe that the high cost of some application development is due to the fact 
that the designer (or design
team) is/are clueless about the actual application requirements (computer 
science majors) or they are clueless
about the platform capabilities (business/accounting majors).  I agree with 
your bent towards design, without
quality design you've got squat for product and a high cost/low LOC/man-year as 
a result.

Oh, I almost forgot, finish with an up note ... like your tie.

James W. Kilgore
email@James-W-Kilgore.com

P.S. If we ever meet in 3d I'm gonna duck first and say hi later! ;-)

>
>
> Regards,
> Simon Coulter.
>
> //--------------------------------------------------------------
> // FlyByNight Software         AS/400 Technical Specialists
> // Eclipse the competition - run your business on an IBM AS/400.
> // Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
> // Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au
> //
> // Windoze should not be open at Warp speed.
> //--- forwarded letter -------------------------------------------------------
> > X-Mailer: Microsoft Outlook Express 4.72.3155.0
> > Date: Sun, 10 Jan 99 23:36:04 -0500
> > From: "Dennis Lovelady" <dennis@lovelady.com>
> > To: MIDRANGE-L@midrange.com
> > Reply-To: MIDRANGE-L@midrange.com
> > Subject: Re: AS/400 Gasping For Air ??
>
> >
> > Hi, Simon:
> >
> > >12 years is too low.  Much of the code in OS/400 came from the
> > >System/38.  That's why OS/400 is known as XPF
> > >internally.  eXtended control Program Facility -- many of you
> > >will remember the OS for the S/38 was called
> > >CPF.  The new lads and lassies have just learned something --
> > >does that make me a geezer or do I have to
> > >remember toggling in the bootstrap code in Octal before
> > >I qualify?  So lets average over 20 years.
> >
> > Yes, these make for much more reasonable numbers or workers on the project 
>of
> > O/S.  What I was trying to resolve, is whether IBM uses that number in fact,
> > or only in estimating a project (I believe that the LOC estimate came from
> > the IBM consulting group, unless I misremember).  The original comments were
> > stating that a project was going to take a certain amount of time, because 
>of
> > the 2000 LOC/year/person, so I used a roundabout way of getting a
> > demonstration of those numbers in practice.  Thank you for doing so, Simon.
> > As it turns out, the numbers would seem to be at least palpable, given your
> > explanation of the "project" at hand.  I have no doubt of your expertise in
> > this area - you and I go back a ways.  :^)
> >
> > Of course, a very large portion of that (or any) project would be in design,
> > information gathering, "how to," user discussions, organization, file
> > layouts, database design, process structure, goal definition, documentation,
> > redesign, etc.  Probably, this is on the order of more than 50% of the
> > project.  (Out of curiosity, what's a reasonable % for this sort of
> > overhead?)  Given that the original question had to do with replacing an
> > existing system, I still have to wonder if the estimate was not tremendously
> > overstated, since most of that work has already been done (assuming that the
> > new product will be an exact or near emulation of the original).  Still, the
> > budgeted amount of the time would seem to be much too small for the project
> > at hand.
> >
> > Thanks for your patience, Simon.
> > --
> > Dennis Lovelady                    Simpsonville, SC
> > mail: dennis@lovelady.com
> > URL:  http://lovelady.piedmont.net
> > ICQ:  5734860
> > --
> > I just forgot my whole philosophy of life!!!
> >
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator: 
>david@midrange.com
> > +---
> >
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---