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
