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: 101deb,3488d9e5d292649f X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-26 05:44:22 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!peernews-us.colt.net!newsfeed.news2me.com!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.pl1,comp.lang.ada Subject: Re: Quality (Re: status of PL/I as a viable language) Date: Wed, 26 Feb 2003 08:43:24 -0500 Organization: MindSpring Enterprises Message-ID: References: <1045856952.418085@master.nyc.kbcfp.com> NNTP-Posting-Host: d1.56.bd.1c X-Server-Date: 26 Feb 2003 13:44:22 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.pl1:4462 comp.lang.ada:34606 Date: 2003-02-26T13:44:22+00:00 List-Id: Anders Wirzenius wrote in message news:c2Z6a.27$bW6.8@read3.inet.fi... > > Product here means finished product, right? Maybe. Maybe it means "an executable image that is capable of undergoing test". You do some programming. You produce an image. You conduct some tests. You find some bugs. Go back to the beginning. If you found zero bugs, that saves you time and money, correct? It means that what you built is of high quality. > My posting was an attempt to describe the words "build in quality". Which I think has to come from proper design and proper processes. Its no different from a widget manufacturer with his assembly line. The design of the widget has to be sufficient for its task and the assembly line & tools used there have to accurately realize that design. When the widget comes out of any phase of the assembly line and is inspected, finding an error in it then is not "built in quality". > When you are building something you have always something _half done_. To build in quality means to me that you convince yourself > that this _half done_ is on the right track. The key question is: how do you do the convincing? > I'm not sure what you mean by "half done" here? You are suggesting that the iterative "code/compile/test/debug" cycle is just a natural part of building software and finding bugs in that cycle doesn't count towards poor quality? I think that this would not be a very helpful view in terms of developing "quality" products because it implies that rework is O.K. Rework always implies that you are building something poorly and always implies additional expense. Most industries recognize that the sooner you catch something and eliminate the problem, the cheaper it is to fix. They also accept that if you don't put the defect into the product, it doesn't cost you anything to take it out. Hence the notion of "built in quality" MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ======================================================================