A rocket was destroyed by a fragment of an older rocket, still running, performing a task that no longer existed. That is what advancement actually looks like, and it is why a starship would fall.
"The people aboard do not know what all of it does. They cannot. The quantity of inherited machinery in any system that advanced exceeds what any individual or any team can hold, and this is not a deficiency in them, it is the definition of the thing they are operating. To be advanced is to be carrying more history than you can audit.
And given enough operations, the encounter happens. Some old assumption meets a condition it was never written for. Not because anyone was careless. Because the number of operations kept increasing and the assumption kept being carried forward and eventually the two intersect. That is not a risk. Over a long enough run it is a schedule."
Sounds like a description of every large scale AI application. Will anyone know, in detail, what the app does or how it does it? If not, it's an automatic recipe for human, legal and financial disaster.
Almost didn’t read because of the hokey AI/SciFi illustration, but brilliant. I struggled often enough trying to explain to CFOs the monetary value of institutional knowledge and to quantify technical debt. This perspective would have increased the number of my limited successes, but alas, that number declined over my career (now retired), as it *seemed* to support the very notion of “move fast and break things” that I was arguing against.
A business environment of ‘get mine, get out’ does not care on an interstellar timescale.
I remember visiting NASA in Houston yonks ago, I think with a Sperry Univac team, talking about the code running on their hardware - surely the COBOL and Fortran programmes would have been re-written in RUST or some version of C+, and (surely?) would not automatically include sub-routines for older systems ... as rocketry advances so too does software and languages.
No, and the reason is certification rather than coding. Under DO-178C the deliverable is the evidence, not the code: traceability, structural coverage, independent verification. Rewriting in Rust throws all of that away and you start the package again. So the old proven thing gets carried forward every time.
Ariane 5 is the proof. New rocket, new hardware, and they reused the Ariane 4 software regardless.
About eighty-five percent of the Shuttle ran on HAL/S, a language built for NASA in 1972. Nobody rewrote it in thirty-eight years.
Your essay suggests that legacy certifications are themselves the culprit - may be hope for the Musk break-everything-and-try-again approach rather than the legacy nasa/ESA tried-and-true approach (as much as it pains me to say it): perhaps a parallel - be more like Ukraine and less General Dynamics?
Partly. Though iterating fast works because failure is cheap and the loop is short. Certification exists for the case where the first flight has passengers aboard. SpaceX blew up Starships and also ran the full human-rating process for Dragon, which tells you they know the difference.
And Falcon 9 flight software has been accumulating since 2010. The oldest of it is now older than the Ariane 4 code that killed Ariane 5. Moving fast does not prevent the sediment. It just keeps yours younger, for a while.
Looks like you are writing about why there will never be a Human Colony on Mars. If so, you are so very correct. Nobody is going to be landing on Mars. It’s a ridiculous and suicidal idea, going to Mars. But, I won’t mind if Elon goes.
It was not what I set out to write, but you are right that the argument goes there, and Mars is where it bites hardest. Every factor gets worse at once. You cannot iterate, because the launch windows are about twenty-six months apart. You cannot talk anyone through a problem in real time, because a message takes up to twenty minutes each way. And whatever is inherited in those systems has to keep being correct with nobody in a position to come and fix it.
"The people aboard do not know what all of it does. They cannot. The quantity of inherited machinery in any system that advanced exceeds what any individual or any team can hold, and this is not a deficiency in them, it is the definition of the thing they are operating. To be advanced is to be carrying more history than you can audit.
And given enough operations, the encounter happens. Some old assumption meets a condition it was never written for. Not because anyone was careless. Because the number of operations kept increasing and the assumption kept being carried forward and eventually the two intersect. That is not a risk. Over a long enough run it is a schedule."
Sounds like a description of every large scale AI application. Will anyone know, in detail, what the app does or how it does it? If not, it's an automatic recipe for human, legal and financial disaster.
There’s never enough time to do it right, but there’s always enough time to do it over.
Almost didn’t read because of the hokey AI/SciFi illustration, but brilliant. I struggled often enough trying to explain to CFOs the monetary value of institutional knowledge and to quantify technical debt. This perspective would have increased the number of my limited successes, but alas, that number declined over my career (now retired), as it *seemed* to support the very notion of “move fast and break things” that I was arguing against.
A business environment of ‘get mine, get out’ does not care on an interstellar timescale.
I remember visiting NASA in Houston yonks ago, I think with a Sperry Univac team, talking about the code running on their hardware - surely the COBOL and Fortran programmes would have been re-written in RUST or some version of C+, and (surely?) would not automatically include sub-routines for older systems ... as rocketry advances so too does software and languages.
No, and the reason is certification rather than coding. Under DO-178C the deliverable is the evidence, not the code: traceability, structural coverage, independent verification. Rewriting in Rust throws all of that away and you start the package again. So the old proven thing gets carried forward every time.
Ariane 5 is the proof. New rocket, new hardware, and they reused the Ariane 4 software regardless.
About eighty-five percent of the Shuttle ran on HAL/S, a language built for NASA in 1972. Nobody rewrote it in thirty-eight years.
Your essay suggests that legacy certifications are themselves the culprit - may be hope for the Musk break-everything-and-try-again approach rather than the legacy nasa/ESA tried-and-true approach (as much as it pains me to say it): perhaps a parallel - be more like Ukraine and less General Dynamics?
Partly. Though iterating fast works because failure is cheap and the loop is short. Certification exists for the case where the first flight has passengers aboard. SpaceX blew up Starships and also ran the full human-rating process for Dragon, which tells you they know the difference.
And Falcon 9 flight software has been accumulating since 2010. The oldest of it is now older than the Ariane 4 code that killed Ariane 5. Moving fast does not prevent the sediment. It just keeps yours younger, for a while.
You know HAL? I just found out about YOU.
👁️ found🐑.
Looks like you are writing about why there will never be a Human Colony on Mars. If so, you are so very correct. Nobody is going to be landing on Mars. It’s a ridiculous and suicidal idea, going to Mars. But, I won’t mind if Elon goes.
It was not what I set out to write, but you are right that the argument goes there, and Mars is where it bites hardest. Every factor gets worse at once. You cannot iterate, because the launch windows are about twenty-six months apart. You cannot talk anyone through a problem in real time, because a message takes up to twenty minutes each way. And whatever is inherited in those systems has to keep being correct with nobody in a position to come and fix it.
Fascinating