Everyone who writes safety critical software should read this

[eles]

On Wednesday, 30 October 2013 at 20:06:19 UTC, Walter Bright 
wrote:
> On 10/30/2013 12:24 PM, H. S. Teoh wrote:
>> On Tue, Oct 29, 2013 at 07:14:50PM -0700, Walter Bright wrote:
> There's still plenty of reason to improve software quality.
>
> I just want to emphasize that failsafe system design is not 
> about improving quality.

I did follow this thread for a while and it happens that I am 
working on this kind of software.

I won't really know to say why it works, but several elements 
help with that:

-some quite strict code style guidelines (it also helps a lot 
when working on some legacy code)
-a small team of "safety" whose sole job is to question the code 
produced by us (I am among those developing) on the basis: "here, 
here, what happens if this fails?"
-some analysis and traceability (you know: the "process" thing) 
tools that help both with code (MISRA-C, clang etc.) and 
documentation
-good bug tracking and thorough discussion of the problem at hand 
before and after implementation
-the developers themselves questioning their own every LOC they 
write

No code is accepted unless it has a way to fail graciously. For 
this reason, unrolling changes in case of errors is a great 
proportion in code, so having that scope() statement would be 
pure gold for me.

Basically, I think that critical code is almost always developed 
as if being transaction-based. It succeeds or it leaves no trace.

OTOH, things that I would really like to work better are:

-greater flexibility of the management when a developer tells: "I 
think this code part could be improved and some refactoring will 
help"
-an incremental process, that is the management should assume 
that the first shipped version is not perfect instead of assuming 
that it is perfect and not being prepared for change requests