211–220 of 327 posts
Earlier quoted context omitted.
Multiple books have been written on this very topic, but the TL;DR is that the problem was not the engineering, but the absurd, often mutually contradictory design decisions forced on it for political reasons. https://en.wikipedia.org/wiki/Space_Shuttle_design_process
The irony is this kind of describes k8s as well.
Earlier quoted context omitted.
But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.
tests -> verify intended functionality implementation (the how is right). comments -> why intended functionality was implemented that specific way (marketing wanted X because of Y, so we had to do it like Z with a bit of A). > But comments go out of date Just like updating the tests when code is changed, update the comment when the code is changed.
The same people who do the bare minimum for tests not to explode. But won’t add a new test case for the new branches they just introduced.
The same people who will mangle the code base introducing bizarre dependencies or copy paste the same piece of code rather than refactor.
People who fail to handle errors correctly. My favorite: by wrapping code in a if statement without an else. (else? Get a weird error without logs! Miles away from the call site!)
People who don’t validate inputs.
People who don’t give a monkey about adding context to errors making the thing impossible to debug in prod when they explode.
People who are too lazy or in incompetent to do their job properly and will always jump at the opportunity to save 5 minutes now but waste 5 hours of everybody else’s time later. Because of course these people can’t fix their own bugs!
And of course these are the people who make comments go out of date. I’ve seen them implement a thing literally the line below a TODO or FIXME comment and not delete the line.
Comments going out of date is a shit excuse for not writing comments as far as I’m concerned.
The fact that some people are incompetent should not drive engineering decisions. You should always assume a minimal level of competency.
Earlier quoted context omitted.
Regressions are not implied by that statement. A bug doesn’t exist in the human realm until a human observes it.
“Program testing can be used to create 1 the presence of bugs, but never to show their absence” 1) edited
Formal proofs may not be silver bullets, and we’re never safe from a faulty implementation of the proven algorithms, but this quanta article on a DARPA project showed impressive results [0].
There’s also AWS’ use of TLA+ [1].
[0]: https://www.quantamagazine.org/formal-verification-creates-h...
Earlier quoted context omitted.
5000 / 17 ≈ 295. Is it a fair assumption to make that a commercial program of equivalent complexity would take 295x fewer man-hours?
No, I don't think so, 295x is a crazy high factor. The article says 260 people are involved, and let's generously say it took 20 years to write the software (the first mission was 10 years after the program started and it was around for a total of 40 years). Dividing by 295 means a commercial team of the same size could have done it in less than a month. Or with a 10x smaller team, about 8 months. I don't think eithe…
Earlier quoted context omitted.
“Program testing can be used to create 1 the presence of bugs, but never to show their absence” 1) edited
That would be the purpose of formal proofs, wouldn’t it? Formal proofs may not be silver bullets, and we’re never safe from a faulty implementation of the proven algorithms, but this quanta article on a DARPA project showed impressive results [0]. There’s also AWS’ use of TLA+ [1]. [0]: https://www.quantamagazine.org/formal-verification-creates-h... [1]: https://news.ycombinator.com/item?id=22082869
You also aren't safe from misunderstanding what it is that you've proven about the program.
Which is actually the same problem as other software bugs; you have a specification of something, but you don't know what it is that you've specified, and you wish it were something other than what it is.
Am I weird in feeling like the code in this file is really really... normal? Like, it's verbose in certain ways due to being written in Go, as well as due to not relying on any deep abstractions (and I don't mind this - abstractions are a double-edged sword), but in general, as code, it seems typical - and if the header text didn't exist I wouldn't think twice about the style it's written in. Maybe the disconnect her…
I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…
I never could understand that code. I know it wasn't brief, does that mean it was explicit?
I think the truth is brevity and explicitness are orthogonal. Let me ask you this: can code be both brief and explicit? What would that look like?
Earlier quoted context omitted.
The situation with the Space Shuttle is more complex than simply poor safety. In terms of missions, it has a better record than many other launch vehicles - 2 fatal missions out of 135 for the shuttle, 2 out of 66 for the Soviet-era Soyuz, and a frighteningly poor 1 fatal mission out of only 12 spaceflights for SpaceShipTwo. However, the Space Shuttle had a much larger crew capacity than most missions probably needed…
> had a much larger crew capacity than most missions probably needed We rarely flew the maximum number of passengers. On non-EVA missions we typically only sent up 5 astronauts. For EVA missions we usually sent up 7 with the two extra crew typically being dedicated to the EVA. EVAs are a real chore. The shuttle is at 14.7 psi with regular atmosphere, but the EVA suits are 4 psi with pure oxygen atmosphere, so you hav…
Space is *insane*. I spent some time with satalite engineers. Space is far beyond hostile.
I loved 'For all mankind." Even with it's problems.
I’ve always disliked how the Go style insists on removing certain branches at the end of functions, for example.