Re: Quality (Re: status of PL/I as a viable language)

["Anders Wirzenius" <anders.wirzenius@pp.qnet.fi>]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:b3igbm$eb8$1@slb2.atl.mindspring.net...
> Anders Wirzenius <anders.wirzenius@pp.qnet.fi> wrote in message
> news:c2Z6a.27$bW6.8@read3.inet.fi...

> > 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

By "half done" I mean that you have something that is not finished to be the end product. It may be a requirements specification. It
may be a flow chart. It is something that describes the goal, the end product. And it should describe it completely (weight, color,
functions, look, odor, packing, customer training ...). The "half done" may be composed of some prototype complemented by
specifications for those parts that you cannot implement using the prototype. If you cannot fulfil size requirements with the proto,
the proto should be enclosed by a specification how big the end product should be. And so on. You then review the whole thing, not
just that part that is in the proto phase.
So, since the "half done" is an instantiation of the complete end product at that particular state, it should be possible to "test"
it against the requirements for the end product.

Maybe I should have used the word review instead of the word test not to mislead people. With "test" I meant any activity to catch
any error or shortage. The word "test" seemed just short and handy to use. I once read about a Japanese company that "tested" their
product requirements specification (which in fact was an instantiation of the end product at that stage) by going out and asking
people what they thought about the product described in the specification. The development project did not continue until the
enquiry results were processed.

> ... You are suggesting that the
> iterative "code/compile/test/debug" cycle is just a natural part of building

No and yes, I am suggesting that you have to do some "testing" of your "half done" (please, understand the word in the wide sence I
tried to describe earlier). You have to know where you are before you can say anything about how much you have deviated from the
right course. You must have something concrete at hand when you do your reviewing. It does not have to be a compiled code. It may be
a flow chart, a state diagram, a whatever, you name it, that you "test". It just has to describe your end product.

> 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

What is the difference between "rework" and "eliminate the problem" or "fix"?

> 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"

That is exactly my point. Fix it while it is cheap. A correction in the specification of the wrapping of the product is much cheaper
than to scrap the packing material at hand and make a new order to the packing material vendor.

My posting was about HOW to find out if you have something cheap to fix.
Unfortunately I just used the wrong word ("test") :-)

Anders