Royal Pain

[David Thornton]

Peter L. Peres wrote:

>On Fri, 18 Jun 2004, Lennart Sorensen wrote:
>
>  
>
>>On Fri, Jun 18, 2004 at 07:27:26AM -0400, James Knott wrote:
>>    
>>
>>>And of course, it's impossible to prove there are no bugs.  You can only
>>>fail to find some.
>>>      
>>>
>>That is actually not true.  If you have a well defined specification of
>>what the behaviour of each piece of the program must be for specific
>>inputs, you can actually prove the behaviour of each part of the program
>>correct.  This is in fact done at some software companies.  It is
>>certainly a lot more work and costs more.  It requires proper bounds
>>checks, and full coverage testing at the very least.
>>    
>>
>
>And that the *specification* be correct. But the specification is
>elaborated by humans (and machines programmed by humans), so ... you can
>say standard compliance is not perfection (can you see the gnu style
>recursion in this statement ?).
>
>Peter
>--
>The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
>TLUG requests: Linux topics, No HTML, wrap text below 80 columns
>How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
>  
>
I read a boot called "Quality without Tears" which totally addressed the 
concept of quality in business. It was a great read. It tries to bring 
that methodical approach that we expect from engineering-like processes 
to "fuzzy" bussinesss related processes. One major thesis of the book 
was "Quality is conformance to specifications". And it went on to talk 
about how you define specification and how important it is to make "bug 
free" specification. And how you measure you work agains your specifcations.

I highly recommend:

"Quality Without Tears
The art of hassle free management"
Philiip B. Crosby
ISBN: 0-452-26398-0
Published: 1985

Philiip B. Crosby originally wrote "Quality is free" which from what I 
gather was a much more popular book (that I have not read). This book, 
"Quality Without Tears", is a followup to that book.

I went to read up on what other people though about the book and I was 
surpriced to find a review on a software developers forum that reads 
something like this:

            "This book give no specific exampels of ohw to make high 
quality software, it sucked."

I thought that that review was hilarious. The book is not specifically 
dirrected at software developers. It address the concept of Quality at a 
much more generic level. I found it entirely applicable and I'm a system 
administrator. Obviously YMMV.

david
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml