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

If anyone's interested: Scientific American did an article last month I
believe (read it on a plane) about methods of estimating software
projects and compared the LOC method (guesswork with an abacus...my
comment) with the Function Point method (weather forecasting). I'll
offer no further opinions for "that way there lies dragons". 

> -----Original Message-----
> From: email@james-w-kilgore.com [SMTP:email@james-w-kilgore.com]
> Sent: Wednesday, January 13, 1999 9:19 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      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
> +---
+---
| 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
+---