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

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

"John R. Strohm" <strohm@airmail.net> wrote in message news:CACF786833CAF67E.50C10DC07731FD2D.0DEBE34F2ECDF3F2@lp.airnews.net...
> It wasn't extremely good; it was PERFECT.  It did PRECISELY what it was
> designed to do.  It did PRECISELY what the customer WANTED it to do.  And it
> didn't just CLAIM to do that, and CLAIM to have no lurking faults; it was
> rigorously KNOWN to have no lurking faults.
>
> This was part of a long project aimed at developing verification technology
> to the point that it would be possible to build perfect software.  One can
> easily envision domains where exhaustive testing is just not possible, where
> it is necessary to KNOW by other techniques that the software is absolutely,
> positively, correct.  In those domains, "debugging" until it LOOKS like it
> works just isn't good enough.
>
>
>

When you talk about quality, I think a key issue is a discussion about  building quality versus testing quality. What means
"building quality into something"?

The paradoxality lies in that you never can avoid the situation of "First Do It And Then Test What You Have Done".
With "testing" I mean any way (test, review ...) to convince that some entity is fulfilling the requirements put on it.
If you write an essay, the only way to have linguistically correct text is to write a sentence and check (test) your sentence. Then
write the next sentence. And check it.
The only way to guarantee that you spread butter all over your slice of bread is to spread the butter and then check that you have
it all over the slice.

So, how do you then _build_ quality into your product or computer program? By "testing" smartly! By taking your time to plan a
"testing" schedule all over the lifetime of the project. By leaving all testing to the end you just create a big bang and hope that
the bang is a positive one. By splitting the development project into smaller pieces the bangs are smaller and hence the damages of
having negative bangs become significantly smaller.

The thing you have to decide is then: How often do I test? How small pieces do I test?
In a software project you have requirements in the beginning and a running software at the end. What you have in between is your own
choice as a project manager. Your choice may be to build a protype and run a test suite on it, create next proto and test it. Or
your choice may be to divide your project into phases of specification, design and coding and have a testing or review after each
phase.
The specification and the final piece of code (maybe together with necessary hardware) both should demonstrate the end product
entirely. Hence it should be possible to test the requirements of the end product on both embodiments. If the tests show shortages
or inaccuracies the embodiment is incomplete and should be corrected before the project continues. If the specification has passed
your tests (or review, whatever), then you KNOW (as John R. Strohm writes) that you have a correct specification of the end product.

My experience of development projects in electronics and steel industry has strengthen my above described opinion about the value of
dividing the whole project into phases. I have participated in projects where we systematically worked through the project starting
from a verbal specification of the product and ending at a hand held measuring device with correct functions and accuracy and look.
I have also seen development projects ending in a bitter situation where the project manager defended his ideas about a successful
product because that discussion was never held earlier in the project. In the latter situation the project manager DID NOT KNOW
whether or not he was on the right track until at the end of the track.

Anders