5 ms·

"We'll fix it in the first patch" Programming for astronomy is famously difficult, since you're always pushing the boundaries one way or another. That said the

by Y_Y 3y ago

"We'll fix it in the first patch" Programming for astronomy is famously difficult, since you're always pushing the boundaries one way or another. That said the problem domain is fairly well specified and (as the article shows) usually well models. Mr. Feynman going to Washington showed what treating astro like office software can do, but it's a shame when an expensive project gets a fleshwound from something predictable. See also: what JAXA launched and x-ray satellite that couldn't stop spinning, or that notorious kerfuffle converting pounds-force-hogsheads into metric that sent a very expensive item off into oblivion.

cratermoon 3y ago
I've noted, unscientifically, space flight problems are now largely about software bugs. Rarely is the hardware the root cause, with notable exceptions like the first SpaceX Starship flight. That tracks for me, as software "engineering" is a long way from any other engineering discipline, including aerospace. > that notorious kerfuffle converting pounds-force-hogsheads into metric that sent a very expensive item off into oblivion. I feel compelled to chime in here and point out there was far more at fault than a units conversion error. “A critical flaw was a program management grown too confident and too careless, even to the point of missing opportunities to avoid the disaster.” https://spectrum.ieee.org/why-the-mars-probe-went-off-course https://spectrum.ieee.org/why-the-mars-probe-went-off-course Look at program management in the aerospace industry and you'll see software treated as an afterthought, or poorly managed and tested. It seems developing space-worthy software is still largely a work in progress.
- pests 3y ago
  I saw a quote on here awhile back. Not sure from where or who said it originally. It was exactly what you realized. We would have intergalactic space travel and von neumann probes by now if it wasn't for software. Materials science, energy production, construction - all solved problems. We just don't have the computer engineering skills to make it all work. I think this also touches on another thing I've always felt about software engineering - we are not a professional field. I have seen programmers complain about having to read the documentation for their tools or that they have to go fix 100 instances of some issue. Contrast this to an engineer on a skyscraper for example - you would never hear "you cant expect me to go re-torque all 1000 bolts! its not my fault the spec sheet put that information 3/4ths into the manual. i didnt get that far!" - but this is exactly how I've seen people treat computer engineering.
  - fn-mote 3y ago
    > Contrast this to an engineer on a skyscraper for example - you would never hear "you cant expect me to go re-torque all 1000 bolts! I'm going to guess that those engineers exist and they just don't work on skyscrapers... or they have software tools that make it easy... or they get paid by the hour and are fine with it. I have no idea what kind of software engineering projects you work on, but perhaps you and I both work with a lot of people that would (should?!) never be allowed near the skyscraper-equivalent software.
    - cratermoon 3y ago
      > skyscraper-equivalent software As far as I know, once skyscrapers are built, they tend to stay where they are. Spacecraft, on the other hand, move around, and do so at astonishing velocities, and need to have hyper-accurate navigation and control. For skyscrapers, modeling the forces that act on the materials and the environment works on known quantities, based on thousands of years of building experience. The biggest failings with spacecraft involved the guidance and navigation systems: the ones that determine where it is, how fast it's moving and in what direction, and how and when to fire the engines to change velocity. The hard part is autonomous control, not static design.
      - namibj 3y ago
        Some, like the Millennium Tower in SF, do suffer from problems that risk flattening entire neighborhoods.
        cratermoon 3y ago
        Yes, and that was a failure in modeling the behavior of the building's supports when subjected to high winds. There's no computer controlling the building's position with a bug that will cause it to flip over and self-destruct. https://en.wikipedia.org/wiki/Ariane_flight_V88 https://en.wikipedia.org/wiki/Ariane_flight_V88
        3y ago
- orbital-decay 3y ago
  > I've noted, unscientifically, space flight problems are now largely about software bugs. Looking at the recent years, I don't really think this is the case. System design and process issues are the most frequent ones. Lack of testing, system logic errors, spec mismatches, rushing, bureaucracy, all that stuff. Mission-critical software has a relatively low footprint and has to follow the spec strictly; the payload can sometimes be made more complex but in this case it's also much less important. Most of the complexity in the spaceflight is in the specs and systems design, and in the testing. Critical software is relatively tiny in comparison, so the failures that can be unambiguously attributed to software bugs are relatively rare. > Rarely is the hardware the root cause Hardware and software is typically the immediate cause, not the root cause.
  - cratermoon 3y ago
    You're correct in identifying system design and process issues as being involved. Identifying immediate and root causes gets into systemantics, but note that what you identify is largely about the software now, not the hardware. Rocket design is, more or less, a solved problem, provided it stays within engineering tolerances, well back from the leading edge.

by Y_Y 3y ago

cratermoon 3y ago

I've noted, unscientifically, space flight problems are now largely about software bugs. Rarely is the hardware the root cause, with notable exceptions like the first SpaceX Starship flight. That tracks for me, as software "engineering" is a long way from any other engineering discipline, including aerospace. > that notorious kerfuffle converting pounds-force-hogsheads into metric that sent a very expensive item off into oblivion. I feel compelled to chime in here and point out there was far more at fault than a units conversion error. “A critical flaw was a program management grown too confident and too careless, even to the point of missing opportunities to avoid the disaster.” https://spectrum.ieee.org/why-the-mars-probe-went-off-course https://spectrum.ieee.org/why-the-mars-probe-went-off-course Look at program management in the aerospace industry and you'll see software treated as an afterthought, or poorly managed and tested. It seems developing space-worthy software is still largely a work in progress.

pests 3y ago
I saw a quote on here awhile back. Not sure from where or who said it originally. It was exactly what you realized. We would have intergalactic space travel and von neumann probes by now if it wasn't for software. Materials science, energy production, construction - all solved problems. We just don't have the computer engineering skills to make it all work. I think this also touches on another thing I've always felt about software engineering - we are not a professional field. I have seen programmers complain about having to read the documentation for their tools or that they have to go fix 100 instances of some issue. Contrast this to an engineer on a skyscraper for example - you would never hear "you cant expect me to go re-torque all 1000 bolts! its not my fault the spec sheet put that information 3/4ths into the manual. i didnt get that far!" - but this is exactly how I've seen people treat computer engineering.
- fn-mote 3y ago
  > Contrast this to an engineer on a skyscraper for example - you would never hear "you cant expect me to go re-torque all 1000 bolts! I'm going to guess that those engineers exist and they just don't work on skyscrapers... or they have software tools that make it easy... or they get paid by the hour and are fine with it. I have no idea what kind of software engineering projects you work on, but perhaps you and I both work with a lot of people that would (should?!) never be allowed near the skyscraper-equivalent software.
  - cratermoon 3y ago
    > skyscraper-equivalent software As far as I know, once skyscrapers are built, they tend to stay where they are. Spacecraft, on the other hand, move around, and do so at astonishing velocities, and need to have hyper-accurate navigation and control. For skyscrapers, modeling the forces that act on the materials and the environment works on known quantities, based on thousands of years of building experience. The biggest failings with spacecraft involved the guidance and navigation systems: the ones that determine where it is, how fast it's moving and in what direction, and how and when to fire the engines to change velocity. The hard part is autonomous control, not static design.
    - namibj 3y ago
      Some, like the Millennium Tower in SF, do suffer from problems that risk flattening entire neighborhoods.
      - cratermoon 3y ago
        Yes, and that was a failure in modeling the behavior of the building's supports when subjected to high winds. There's no computer controlling the building's position with a bug that will cause it to flip over and self-destruct. https://en.wikipedia.org/wiki/Ariane_flight_V88 https://en.wikipedia.org/wiki/Ariane_flight_V88
        3y ago
orbital-decay 3y ago
> I've noted, unscientifically, space flight problems are now largely about software bugs. Looking at the recent years, I don't really think this is the case. System design and process issues are the most frequent ones. Lack of testing, system logic errors, spec mismatches, rushing, bureaucracy, all that stuff. Mission-critical software has a relatively low footprint and has to follow the spec strictly; the payload can sometimes be made more complex but in this case it's also much less important. Most of the complexity in the spaceflight is in the specs and systems design, and in the testing. Critical software is relatively tiny in comparison, so the failures that can be unambiguously attributed to software bugs are relatively rare. > Rarely is the hardware the root cause Hardware and software is typically the immediate cause, not the root cause.
- cratermoon 3y ago
  You're correct in identifying system design and process issues as being involved. Identifying immediate and root causes gets into systemantics, but note that what you identify is largely about the software now, not the hardware. Rocket design is, more or less, a solved problem, provided it stays within engineering tolerances, well back from the leading edge.