- cross-posted to:
- hackernews@lemmy.smeargle.fans
- hackernews@derp.foo
- space@beehaw.org
- cross-posted to:
- hackernews@lemmy.smeargle.fans
- hackernews@derp.foo
- space@beehaw.org
You must log in or # to comment.
The Apollo moon landing conspiracists are gonna love this!
Amusingly, I recall reading how a lot of the knowledge from the Apollo program has now been lost. People who worked on it mostly retired, and a lot of the documentation is now gone. So, US would have to rediscover a lot what’s been learned from scratch to replicate the program today.
That is a common myth that was spread about specifically the Saturn program (the rocket that got Apollo to the moon).
The information is not lost at all; and the blueprints for the rocket and practically all the data NASA collected are stored on microfilms kept in NASA headquarters. It was simply never released to the public at large, only academics and research institutions, because the information could be retrofitted to create ICBM’s. It is set to be declassified in a decade or two.
Ironically the source for this myth is the same Apollo conspiracy morons mentioned before. It’s supposed to be some sort of “Gotcha”, but is a straight lie.
While some original documents were lost, that was only really due to neglect, as those documents have been copied many times or were generally not useful, so losing the original wasn’t a concern.
I actually suspect there’s at least some truth to this. I’ve worked on large software projects and I’ve seen this problem first hand. My experience is that no matter how much documentation you aim to write, a lot of the knowledge stays in the heads of the people who designed the project because all the information requires a lot of context to work with meaningfully. When a new person inherits a project it’s practically impossible for them to understand all the nuances of how and why things work the way they do. This same problem applies to any sort of large projects where lots of people have to work together to design a complex system. Once you shut down the program and people who built it retire, much of that knowledge becomes lost.
And here’s an example of this happening at Raytheon recently where they had to call up retirees to help them make stinger missiles https://www.defenseone.com/business/2023/06/raytheon-calls-retirees-help-restart-stinger-missile-production/388067/
I absolutely agree, but I am genuinely saying that they have proof of having anything. They haven’t lost the Library of Alexandria of their research. Research institutes have attested to everything being there. Plus the science is very well understood, and even if they wanted to go to the moon, they wouldn’t just build a copy paste of the Saturn 5.
Yeah that’s fair, the general knowledge is obviously still there. I’m just saying that there would be a lot of work to replicate the effort. Also agree that a new moon program would be based on the tech currently available. So, it is kind of a moot point as you wouldn’t want to build an exact copy of a Saturn 5 today.
Nonsense, they just need to make a Dockerfile and Bob’s your uncle 😜 https://github.com/chrislgarry/Apollo-11
ha
Yes I second this. I’m often doing what I can archeology on code. “What were the ancients thinking at the time? There just have been some reason they did this”.
Not just with the details of the code itself, sometimes there can be large amounts of functionality that make no sense.
A while back I was chatting to an older guy who worked with one of the old mainframes that we still have and he was able to explain to me why we did things the way we did. It was because another external system was very slow and batch orientated. It needed its data asap to begin its processing or it works finish too late. So we had a whole orchestration about sending some data at different times and data marked with different priorities etc.
When the performance requirement disappeared with hardware improvements, the orchestration made no sense anymore, but nobody remembered why we did it that way, so we kept doing it for years after it was needless and stupid.
There was no way you could figure out the why unless you knew the history of the external system.
Often you know the what, but not the why.
That’s a great example. There are a lot of implicit requirements that result from business processes, hardware configuration, org structure, and so on. Nobody really even thinks of these things as requirements at the time, and reverse engineering all that later on becomes impossible. This a great article on this phenomenon that likens long running software projects to living on a generation ship :)
https://medium.com/@wm/the-generation-ship-model-of-software-development-5ef89a74854b
With older projects, even when all of the documentation and the blueprints are still there, it is often the case that the expertise required to read and understand them is no longer there since industry standards for documentation change over time, those who enter the field today learn only the modern standards and those who still got to work with the old standards have retired. I’m not saying that this is definitely the case here but i would not be surprised if the younger generations of engineers who are used to CAD methods would have some struggle understanding old school technical drawings.
Why would you name your death machine after a creature notoriously difficult to keep alive? EDIT: oh it’s a rocket.
thank god
