Everyone who writes safety critical software should read this

[Chris]

On Friday, 1 November 2013 at 13:52:01 UTC, Wyatt wrote:
> On Thursday, 31 October 2013 at 21:36:11 UTC, eles wrote:
>>
>> Yeah, maybe is a corporation culture to avoid the term "bug", 
>> but we always use the term "change request". Maybe it has a 
>> better image :)
>>
> Lately, I've instead been reframing my thinking toward parity 
> with Dijkstra.  EWD1036 [0] is particularly relevant to this 
> topic:
>
> "We could, for instance, begin with cleaning up our language by 
> no longer calling a bug a bug but by calling it an error. It is 
> much more honest because it squarely puts the blame where it 
> belongs, viz. with the programmer who made the error. The 
> animistic metaphor of the bug that maliciously sneaked in while 
> the programmer was not looking is intellectually dishonest as 
> it disguises that the error is the programmer's own creation. 
> The nice thing of this simple change of vocabulary is that it 
> has such a profound effect: while, before, a program with only 
> one bug used to be 'almost correct', afterwards a program with 
> an error is just 'wrong' (because in error)."
>
> As a bonus, my experience is it more readily encourages 
> management types to accept that fixing them is important.
>
>> Normally, it is assumed that passing the tests proves that 
>> specifications are accomplished, so the software is perfect.
>>
>> This, of course, if the tests themselves would be correct 100% 
>> and *really* extensive.
>>
> Again from EWD1036:
>
> "Besides the notion of productivity, also that of quality 
> control continues to be distorted by the reassuring illusion 
> that what works with other devices works with programs as well. 
> It is now two decades since it was pointed out that program 
> testing may convincingly demonstrate the presence of bugs, but 
> can never demonstrate their absence. After quoting this 
> well-publicized remark devoutly, the software engineer returns 
> to the order of the day and continues to refine his testing 
> strategies, just like the alchemist of yore, who continued to 
> refine his chrysocosmic purifications."
>
> This passage comes just after he laments that "software 
> engineer" had been diluted so thoroughly as to be meaningless.  
> (I'd greatly appreciate if this term could be reclaimed, 
> honestly.  Experience has shown me quite clearly that not every 
> programmer is an engineer.)
>
> -Wyatt
>
> [0] 
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

No, not every programmer is an engineer. But not every programmer 
writes safety critical code. If Firefox crashes, nobody dies as a 
consequence (hopefully!).