Comment by WalterBright | Hacker News Reader

Comment by WalterBright | Hacker News Reader

Parent Full thread

Some principles:

1. Code that looks right should be right, code that looks wrong should be wrong. (I know this sounds trite, but there are many examples.)

2. When a program self-detects a fault in its logic, it must stop immediately, as it no longer will be in a known state. (It's still common practice to imagine one can recover from an assertion failure. I've spent many, many hours trying to convince other programmers of this.)

3. Better education will not prevent programming bugs. Better process and mechanical checking will. (This notion has been gaining a lot of momentum.)

4. Reliable systems can be built from unreliable components. https://www.digitalmars.com/articles/b39.html

> Do you think these advantages are common among those who have (mech/electrical/chem/etc.) engineering education and training who move into software development?

Heck, they haven't even trickled into the nuclear power industry (Fukushima), the oil business (Deepwater Horizon), or the automobile industry (Toyota surging problem). Those disasters taught lessons learned by the aviation industry decades earlier.

See also:

https://www.slideshare.net/dcacm/patterns-of-human-error

Perhaps I should amend my earlier statement that it's experience in the aviation business that I've taken over to software. My engineering training was mostly about math, not cutting metal and the nut behind the wheel.

I appreciate the principles, thank you for sharing them.

I started my career in automotive manufacturing before becoming a business analyst on a team developing in-house business automation tools. The program I studied did cover an engineering design process. We were taught to quantify design requirements (subject to a static load of this much, must be within these dimensions, and so on) and use a combination of calculations, simulations, and prototypes to check we are meeting those design specifications.

I am assuming that you would have done something similar in aerospace. If so, have you carried over any of that into software development? Do you have any guidance or D design documents you can point to? The D specification is the final product, but I’m trying to gain a better understanding of how one gets to that final specification.

Thanks for your time!

You're right, we did this a lot at Boeing. I am very proud of the fact that none of my designs needed to be modified once the metal was cut, and it all passed test and certification without any problems.

Software development, on the other hand, lends itself very well to iterative development. You don't have problems like sinking a new forging die costing half a million bucks, so work really diligently to not need to scrap a die. Keep making mistakes like that, and Boeing will move you to a position where you get to design ash trays.

D is very much an iteratively developed product.

3. Better education will not prevent programming bugs. Better process and mechanical checking will.

I don't know if this is what you meant by mechanical checking, but I highly rate two things to reduce bugs:

(1) Checking that the output of the entire system is 100% (and I meant 100% literally in every sense of the word) accurate, not just that the smaller unit tests pass or that the output "looks right".

(2) Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.

As a dev with a data science background, I'm always impressed how many bugs pure devs are able to smuggle in whenever the task involves any kind of data, despite extensive unit testing. I check out their code, run it once, and immediately see the output is wrong and then they have to go back and debug. If we just check our output that wouldn't be the case!

A simple example of mechanical checking would be:

    int[10] a;
    a[10] = 3;  // Error, array index out of bounds

The idea is to allow powerful metal code, while providing constructs that make errors much less likely. For example,

    if (a < b < c)

is allowed by C, but few C programmers can tell you what it means, and the appearance of it in code is almost always a bug. Instead of educating programmers with "don't do that", D makes it illegal. (If you really want it, you'd have to write it as: `(a < b) < c`. But notice you have to make an effort to write code that way, it is highly unlikely to be accidentally written.)

> Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.

I find it useful to go back through the logic a couple months later. I usually find a lot to improve :-)

Reply on news.ycombinator.com