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?
@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.
@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 @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.