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.
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.
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.
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 :)
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