5 ms·

I like this quote: “We didn’t design them to last 30 years or 40 years, we designed them not to fail,” John Casani, Voyager project manager from 1975 to 1977,

I like this quote: “We didn’t design them to last 30 years or 40 years, we designed them not to fail,” John Casani, Voyager project manager from 1975 to 1977, says in a NASA statement.

jfengel 2y ago
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.
- sumeno 2y ago
  Maybe the guy who helped launch the two manmade objects furthest from earth knows more about how to build space probes than you
  - KennyBlanken 2y ago
    Shhhh, this is HN, where just like on reddit, a bunch of computer programmers think they know more than a professional in said professional's field.
    - pvaldes 2y ago
      > this is HN, a bunch of computer programmers think they know more than <figure of authority> 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.
      - yodon 2y ago
        You might be surprised to read the papers written by those early software developers. They were writing in the late 1960's and early 1970's about fundamental issues most developers of today don't fully grasp. 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.
        tucnak 2y ago
        > if you aren't thinking about Amdahl's law you're just a hacker and not actually an engineer. This is really funny stuff, thank you!
      - jvanderbot 2y ago
        The longevity of Voyager has only a little to do with software engineering, and latest software engineering has even less to do with building spacecraft like Voyager.
        Dalewyn 2y ago
        If anything I expect modern software engineering to have significantly higher risks of failure than programmers of ye olde days. 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. [1]: https://news.ycombinator.com/item?id=42162380 https://news.ycombinator.com/item?id=42162380 [2]: https://news.ycombinator.com/item?id=41217037 https://news.ycombinator.com/item?id=41217037
    - dehrmann 2y ago
      Imagine what would happen if a dot-com billionaire started a space company.
      - Ponet1945 2y ago
        Said dot-com billionaire being a physicist who only went into dot-com to earn money to start a space company.
  - zelphirkalt 2y ago
    That's an authority argument, even if in this case a strong one. What you seem to be overlooking is, that merely from this one quote, we cannot conclude, whether that is really all of methodology that went into building the Voyager 1 and 2. So while it is a witty quote, it doesn't actually tell us much, without additional statement, that we don't need to look any further for other methods that were applied.
- yodon 2y ago
  >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. 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).
  - thebruce87m 2y ago
    >This is what happens when you have the best minds committed to designing systems that don't fail. And a budget to support them.
- exmadscientist 2y ago
  Incidentally, you have the question backwards: no one really cares when it's going to fail. We care when it's not going to fail: will the spacecraft make it to its destination or not? It doesn't really matter what happens after that. 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!
- mannykannot 2y ago
  I imagine there are cases which exemplify your point, but this does not look like one of them.
- NavinF 2y ago
  FWIW his quote also applies to a lotta devices here on Earth. For example guns are not designed to last forever, but they are designed not to fail. You don't want to hear a click when you expect a bang or vice versa. As a side effect, they last forever. It's fairly common for a 100 year old gun to work perfectly in 2024.
  - xpe 2y ago
    There are also expectations about maintenance and some notion of a “standard” environment. For example, unmaintained firearms work less well (or fail) when exposed to humid conditions. See also: https://www.nps.gov/subjects/museums/upload/10-01_508.pdf https://www.nps.gov/subjects/museums/upload/10-01_508.pdf
- thowawatp302 2y ago
  You don’t do it that way. You figure out the how it’s gong to fail, when that failure is likely, and then engineer it not to do that in the relevant timeframe. The original engineer was right and you are not.
xpe 2y ago
I would expect a mindful trade-off against total system mass and cost.

I like this quote: “We didn’t design them to last 30 years or 40 years, we designed them not to fail,” John Casani, Voyager project manager from 1975 to 1977, says in a NASA statement.

jfengel 2y ago

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.

sumeno 2y ago
Maybe the guy who helped launch the two manmade objects furthest from earth knows more about how to build space probes than you
- KennyBlanken 2y ago
  Shhhh, this is HN, where just like on reddit, a bunch of computer programmers think they know more than a professional in said professional's field.
  - pvaldes 2y ago
    > this is HN, a bunch of computer programmers think they know more than <figure of authority> 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.
    - yodon 2y ago
      You might be surprised to read the papers written by those early software developers. They were writing in the late 1960's and early 1970's about fundamental issues most developers of today don't fully grasp. 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.
      - tucnak 2y ago
        > if you aren't thinking about Amdahl's law you're just a hacker and not actually an engineer. This is really funny stuff, thank you!
    - jvanderbot 2y ago
      The longevity of Voyager has only a little to do with software engineering, and latest software engineering has even less to do with building spacecraft like Voyager.
      - Dalewyn 2y ago
        If anything I expect modern software engineering to have significantly higher risks of failure than programmers of ye olde days. 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. [1]: https://news.ycombinator.com/item?id=42162380 https://news.ycombinator.com/item?id=42162380 [2]: https://news.ycombinator.com/item?id=41217037 https://news.ycombinator.com/item?id=41217037
  - dehrmann 2y ago
    Imagine what would happen if a dot-com billionaire started a space company.
    - Ponet1945 2y ago
      Said dot-com billionaire being a physicist who only went into dot-com to earn money to start a space company.
- zelphirkalt 2y ago
  That's an authority argument, even if in this case a strong one. What you seem to be overlooking is, that merely from this one quote, we cannot conclude, whether that is really all of methodology that went into building the Voyager 1 and 2. So while it is a witty quote, it doesn't actually tell us much, without additional statement, that we don't need to look any further for other methods that were applied.
yodon 2y ago
>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. 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).
- thebruce87m 2y ago
  >This is what happens when you have the best minds committed to designing systems that don't fail. And a budget to support them.
exmadscientist 2y ago
Incidentally, you have the question backwards: no one really cares when it's going to fail. We care when it's not going to fail: will the spacecraft make it to its destination or not? It doesn't really matter what happens after that. 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!
mannykannot 2y ago
I imagine there are cases which exemplify your point, but this does not look like one of them.
NavinF 2y ago
FWIW his quote also applies to a lotta devices here on Earth. For example guns are not designed to last forever, but they are designed not to fail. You don't want to hear a click when you expect a bang or vice versa. As a side effect, they last forever. It's fairly common for a 100 year old gun to work perfectly in 2024.
- xpe 2y ago
  There are also expectations about maintenance and some notion of a “standard” environment. For example, unmaintained firearms work less well (or fail) when exposed to humid conditions. See also: https://www.nps.gov/subjects/museums/upload/10-01_508.pdf https://www.nps.gov/subjects/museums/upload/10-01_508.pdf
thowawatp302 2y ago
You don’t do it that way. You figure out the how it’s gong to fail, when that failure is likely, and then engineer it not to do that in the relevant timeframe. The original engineer was right and you are not.

xpe 2y ago

I would expect a mindful trade-off against total system mass and cost.