This is how NASA writes software:
https://www.fastcompany.com/28121/they-write-right-stuff
I want the software driving cars around my family to be held to the a similar standard of quality. In the context of self-driving cars, "Move fast and break things" means "Half-arse it and kill people."
Humans in the USA manage 1.16 fatalities per 100,000,000 miles travelled. Uber's software couldn't even get to 3 million miles before it killed someone.
We do this properly, or not at all.
@ifixcoinops
1.
>one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do
How's that different from actually writing the code?
>specificity and precision usually found in blueprints
The source code _is_ the blueprint.
Why'd you have 2 versions of blueprints in 2 different languages?
Also further errors can be spotted by comparing the blueprint and the code.
Also error responsibility becomes easily tracked and accounted and this might increase the care of engineers.
Finally you have several people who understand the system deeply.
>serveral peopel who understand the system deeply
If every blueprint review as turned into a code review instead, it would have the same effect IMO.
>Error responsibility becomes easily tracked
But they have only team responsibility and process responsibility. A singel person is never blamed.
Also, you can do that with source code too - `git blame` is your friend.
Also, new errors can be made when implementing the blueprints in code.
@Shamar @ifixcoinops
Also, I can't type anymore :(
s/as turned/was turned/
s/singel/single/
@Wolf480pl @ifixcoinops
Remember that time one of the modules passed a parameter in imperial units and the other module expected them in metric and it caused a billion dollar rocket to blow up?
That could have been prevented by such a deeply detailed blueprint.
@grainloom @ifixcoinops
It really depends on how detailed the blueprint is.
If it says "the function takes a velocity in m/s as an argument" then it would.
But having a javadoc-style comment on the function saying "velocity - the felocity of Foo in m/s" would do it equally well.
`newtype VelocitySI = VelocitySI Integer` whould've been even better at preventing such a mistake.
@Wolf480pl @grainloom @ifixcoinops
I think you miss the point.
It's not the compiler that prevent bugs.
It's not unit test.
It's not integration tests.
Not even if you get 100% branch coverage.
It's the careful review of different people that prevent bugs.
The goal of tests and compiler is to force more and more reviews.
A human readable blueprint reduce the bugs by increasing the diversity of reviewers, and the number of reviews under different mindset.
@Shamar @grainloom @ifixcoinops
but naming a type in a descriptive way communicates the intent pretty well, and makes it easier for the coder to not make the mistake in the first place, and for the reviewer to spot the problem.
Also, compilers, static code analysis, and formal verification help you check the trivial things that people assume without checking. When reading someone's code, I would rather focus on the logic than manually check whether the types are correct.
@Wolf480pl @grainloom @ifixcoinops
> When reading someone's code...
Indeed, that's the reason why people write blueprints.
To read someone else's logic.
@Shamar you still need something that will verify the non-logic.
And you can still make mistakes when implementhing the blueprint into code.
@Wolf480pl @ifixcoinops
> How's that different from actually writing the code?
Actually in a number of ways.
First the human reviews are simpler in a form that is designed for human communication. This could lead to more reviews.
Second the blueprint implementation is a further deep review. It's particularly useful because whenever you find if hard to implement the blueprint or you simply spot something you didn't foresee, you can go back to the drawing board.