From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5a97e6705e234408 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-26 10:06:21 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Expected bytes per sloc (semicolons) performance Date: Wed, 26 Sep 2001 12:58:27 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9ot1fk$fr6$1@nh.pace.co.uk> References: <9oqrgf$jc3$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1001523508 16230 136.170.200.133 (26 Sep 2001 16:58:28 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 26 Sep 2001 16:58:28 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:13405 Date: 2001-09-26T16:58:28+00:00 List-Id: I think my point was that in many cases, prototype code and/or prior experience with similar systems is a luxury that many, if not most projects don't have. I've been on projects where we did have prior experience with very similar systems and could quickly cobble together something that would roughly approximate the new system and use that to gain some reasonably good estimates of timing and sizing. Great if you can do that. What about when you can't? In software, we generally don't build the same thing more than once. While there are systems with incremental improvements or spiral development enhancements, those aren't typically the kind of things where the hardware is being built from bottom dead center and desparately needs some kind of information on what the software is going to require. When it is all brand new is when you most desparately need quality estimates and this is paradoxically when its hardest to make them. In both military and commercial developments, this sort of situation arises often enough and there are a variety of pressures that make it difficult or impossible to build a prototype before you have to commit to hardware decisions. Software development is not quite like most other sorts of engineering development & it has a very hard time with measurement & prediction as a result. Ask a civil engineer to estimate the design and construction time for a building based on some sketches & dimensions and he stands a pretty good chance of doing that pretty well because any one building is sufficiently similar to others that you can base costs on the number of square feet, etc. Us software guys don't get the same luxury because the instant it becomes sufficiently similar to something done before, it gets turned into a subprogram/subsystem with some parameters and the duplication cost is pretty close to zero. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Stephen Leake" wrote in message news:ug09a0ykj.fsf@gsfc.nasa.gov... > > I did just that; get a similar processor or simulator, write some > prototype code. > > Or, agree that you will only make evolutionary changes from the > previous release. That's really the same thing; the previous release > is a good prototype. >