That doesn't seem helpful. Nothing lasts forever, and if you don't figure out when it's going to fail, it's going to be sooner rather than later.
And they are correct
At least on the programming part, having in mind the huge advances in computers since the Voyager was built.
Any professional computer programmer here knows more in their field than a programmer from 70's. A Voyager built today with similar resources would be much better, 100% guaranteed.
Voyager 1 was a fantastic machine done by a terrific team, but lets not pretend that the state of the art hasn't changed. Anybody with computer skills polished towards building a machine in 1977 would be basically unemployable for building a machine in 2024.
You might think, for example "waterfall, ewwww", but if you go back and re-read the first paper on waterfall development, it makes clear that waterfall development is in fact an anti-pattern. How many here are stuck on "modern" teams that think waterfall is a good idea, and yet those clueless old folks had figured out it was a dead end 50+ years ago.
One of the most critical aspects of managing software development is Conway's law. For distributed scalable systems, if you aren't thinking about Amdahl's law you're just a hacker and not actually an engineer. Check the dates on those papers.
They built incredibly sophisticated systems using incredibly primitive building blocks. If you honestly think they couldn't ramp up on PHP or Python or k8s, you need to spend a bit more time around some actual badasses.
This is really funny stuff, thank you!
Why? The first step today would be installing Discord[1], the second step would be updating code live 420 no scope[2], and the third step would be figuring out how many JavaScript abstractions are desired.
Why? Deep space radiation is only 4x the dosage compared to LEO. Starlink satellites use modern tech and they've spent >10,000 collective years in space since we launched more than 2 of them. The whole "modern electronics are more fragile" issue is overblown. The CPUs are tiny and easy to shield. The MMICs use huge features that you can see with a normal microscope.
"Modern electronics are more fragile" issue really is not overblown. One of my peers have tested different types of non volatile memory in LEO and the TLC NAND sample gets totally wiped by ionizing radiation within the first week. CPUs, while being mostly logic and less susceptible to low energy events, can still be easily destroyed especially if radiation causes latchup. MMICs and discrete devices have huge features in comparison yes, but the junctions still degrade notably under radiation.
From my opinion as someone working on LEO satellite hardware, it's easy to have opinions about stuff like correctness and reliability because it is not naturally intuitive and usually requires observation of many samples over a long time that it doesn't affect most engineers. However, I've definitely seen a strong correlation between the effort spent on correctness and reliability, and the success of missions.
Since then, we had massive advantages in manufacturing. Maybe COTS parts aren't as usable in space as they were back then, but we can now easily manufacture something more resilient or, as a fallback, simply use those old parts. Also, basically all current electronics are designed to be and are used on earth ~100% of the time. Over-engineering it for use in space is just a waste.
And is not just software. Reducing an entire computer room to the palm of your hand but with better storage, graphics and computing power is basically black magic. I can't imagine what Voyager could do with a current Nvidia chip.
2) Just because people is not trained in some specific domain does not mean that they couldn't be motivated to do it. I bet that the people that built the Voyager didn't born with the instructions engraved in their brains. And if they learned, other people can also.
If I learned something after lurking HN for a lot of years is to never, ever, underestimate this community. This place stills keep surprising me in good ways.
There are so many abstractions today that you don’t _have_ to know how computers work. They did.
Re: state of the art, you don’t need or want state of the art for building things that go into space, or underwater (closest analogue I can think of that I have experience in [operating, not coding for]). You want them to be rock-steady, with as close to zero bugs as possible, and to never, ever surprise you.
And if we look at the average dev today, most code is in the framework, or a node package, or composer package, and the average dev gets by via stack overflow or AI.
There are certainly devs that actually understand coding, but the average dev barely does. Most devs don't understand the underlying OS, the hardware, or externals such as databases at all. It's all abstracted away.
And coders back then had almost nothing abstracted away.
Programming for regimes with different constraints is…very different. In a very real sense, “their field” for most modern programmers isn’t even the same field as developing software for 1970s deep space probes, plus, the issue wasn’t even about software but about end-to-end building and launching space probes (that was both what the quote was about and the field of the Voyager project manager.
But thanks for demonstrating the kind of hubris that the post you were responding to described.
Developers in the 80 invented every algorithm we can now use with a simple import statement and single line function call.
Your statement is probably true for a minority of developers today, but not "Any professional programmer here"
You might be surprised about the reality of the situation.
I had a professor who worked on the design and fabrication of the Apollo Guidance Computers, which likely was a somewhat similar process to the one being discussed here. It's been quite a few years since his lecture on it, but the process went something like this:
They started with an analysis of the predicted lifetime/reliability of every chip type/component available to potentially include in the design.
The design was constrained to only use components with the top x% of predicted life.
Then they surveyed each manufacturer of each of those component types to find the manufacturer with the highest lifetime components for each of the highest lifetime component types.
Then they surveyed the manufacturing batches of that manufacturer, to identify the batches with the highest lifetimes from that manufacturer.
Then they selected components from the highest lifetime batches of from the highest lifetime manufacturers of the highest lifetime components.
Using those components, they assembled a series of guidance computers, in batches.
They tested those batches, pushing units from each batch to failure.
They then selected the highest quality manufacturing batch as the production units.
When he gave this talk, decades after the Apollo era, NASA had been continuing to run lifetime failure analyses on other units from the production batch, to try to understand the ultimate failure rate for theoretical purposes.
Several decades after the Apollo program ended, they had still never seen any failure events in these systems, and shortly before the time of his lecture, I believe NASA had finally shut off the failure testing of these systems, as they were so remote from then "modern" technology (this was decades ago, hence the quotes around "modern").
This is what happens when you have the best minds committed to designing systems that don't fail. Yes, the systems probably will fail before the heat death of the universe. No, we don't have any idea when that failure time will be. Yes, it's likely to be a very long time in the future.
(And, of course, this is typed from memory about a lecture decades ago on events happening decades before that. This being HN, someone here probably worked on those systems, in which case hopefully they can add color and fix any defects in the narrative above).
And a budget to support them.
> This is what happens when you have the best minds committed to designing systems that don't fail.
Given how times have changed, perhaps it is also valuable to note that other major-yet-unwritten factor: confidence in the supply chain.
This might seem like a nitpick, but changes in approach and mindset like this are often the difference between success and failure with "impossible" problems like this. So it's critical to get your approach right!
The original engineer was right and you are not.
See also: https://www.nps.gov/subjects/museums/upload/10-01_508.pdf