Hacker News new | past | comments | ask | show | jobs | submit login

You know, getting these electronics systems ready, sending out to deep space and communicating with these systems is an incredible feat.

But, for me, another amazing thing about these long term projects is the sheer amount of knowledge that needs to be maintained and passed on to new people, over the course of several decades. To pull it off, this need of knowledge management and transfer must be so deeply engraved in the culture of the organization. How do they do it in this day and age of "FAQs", "Forums" and "Helpdesks"? :)

In all seriousness, what do you do to maintain "knowledge" in your organization?




This is a good insight. Having read about NASA's culture some from books like "An Astronaut's Guide to Life on Earth", they tend to be very dedicated to documenting everything. Every last little detail goes into handbooks or manuals about how they fixed problems or things that could have gotten someone killed, adapting procedures to take into account even the smallest of practical details. These engineers come from a different era. You can see all the printed binders on their desks. I think in many ways the process of documentation for space missions is more expensive, pain staking, and solid than modern practices. I think also they do have the advantage of all working in the same place. You just go to Tom, the human search engine/librarian, and ask him what he knows about thing X. (The article mentioned Tom was the self styled "librarian" of the project). Most organizations need a "Tom" of their own and are poorer for not having one.

Our company is building a remote team, and similar to Gitlab, we are discovering that staying in sync is not just a good value but a way of life. Trello, wiki, and code help us repeat our assessment work and ensure everyone is on the same page.


To give some kind of context on more "modern" methods, we use stupendous numbers of PDFs, DOORS for requirements traceability and tons of code commenting. At last count our project had 0.73 commenting lines per line of code (and we use Allman style bracketing).

We are also putting non mission-critical information in a Wiki; basically as a tl;dr of the more dense documentation.


Oh man, I hated DOORS so much. POS software. I dont doubt its useful, but using it was the bane of my existance


Heh, DOORS is pretty crappy. But once you get used to its flavour of crappiness, you can get shit done.

I think it's one of those tools which demand a lot of expertise in setting them up, or you will paint yourself in a corner, with explosive paint.


Everything you described is just standard engineering practice. I've always found it funny how software developers call themselves "engineers" while working nothing like them.


Everything you described is just standard engineering practice. I've always found it funny how software developers call themselves "engineers" while working nothing like them.

So true. But when you have a culture and an industry where 2 years ia a long tenure at a company and a long lifecycle for the latest faddish "framework" or whatever, it's impossible. I'd love to stay somewhere 10+ years and work on a single significant application the whole time. But it seems to be impossible to find such a gig. Experience is generally undervalued throughout our entire industry.


You can do that at any time. Start a project and work on it forever. I'm still working on a compiler I started in 1982.


"I'd love to stay somewhere 10+ years and work on a single significant application the whole time. "

Try CAD. The industry is full of crusty applications pushing 30 years. I'm sure some of the careers are equally long.


It would be standard practice in a waterfall development methodology which big corporations still use to this day.


I used to work at JPL (and coincidentally was given an opportunity to work on Voyager to update some ground software, but ultimately I passed on it since I was way over committed at the time.)

JPL has a formal database that maintains all its requirements documentation. Though, it isn't very user friendly; and you generally have to know what you are looking for.

When I was there, most of the knowledge transfer happened by talking to the older folks around. As a result, I ended up developing close work relationships with people who had been there for 20-40+ years. The historical context they provided on current and past designs was incredibly useful, and not something you would find in a requirements document.

Software was a different matter. Until recently, when the internal GitHub was introduced, finding and digging through code was not as straightforward. Each team/section maintained their own repos. And there was very little consistency, some used subversion, others cvs, accurev, etc, so it made it difficult to find and read code for projects outside your purview. Naturally, this led to software fiefdoms. In contrast, I work at google now, which is the polar opposite: I can effectively read through the entirety of google3 and send a CL/patch to just about anyone.


You document everything and peer review all the time. NASA has an incredible amount of documentation on anything they do. There are controlled processes for everything so whenever you need to go back and see how someone made something, there is an old document for it. The only thing that can't really be passed down is familiarity. You can have the old engineers write down every process, method, or quirk of a system but the new guy still needs to read all of it and get familiar with the system. Long term projects like these involve a lot of learning from other people so that there is a continuous chain of knowledgeable people running the project, like a master and apprentice kind of situation. And if the chain is ever broken, you come back using the documents and information passed on to get up and running as smooth as possible.


I guess beign a goverment agency helps.

After all they're accountable for spending taxpayer dollars on stuff that can crash, burn, explode, and in order to keep funds coming they must be able to prove they're not just making money vanish for no reason.


Well, above all, you value experience.

Seriously, the degree to which age discrimination is an accepted reality in tech today is a great failing, and one that has enormous hidden costs over time.

Sadly I know a number of extremely talented older engineers who have been discarded like trash only to be constantly rejected in their search for new employment, until some of them just give up. It's remarkably ignorant and short-sighted of employers who practice this kind of discrimination.


It's not short sighted. Most upper management in those sorts of companies isn't there for any kind of a long haul. They win if they can impress the VCs with what they shipped in the last few months, doesn't matter if none of it works, services are crashing and customers are unhappy. Imagine if organizations like NASA only recognized accomplishments like "added a button to such-and-such dashboard."

It's laziness mixed with incompetence mixed with the simple reality that too many companies consider it a competitive advantage that they're completely fucked up in their process and procedure but manage to somehow churn out something anyway.

And if you're not hitting your targets, why, move the target! Imagine how much easier NASA's job would be if they could say the moon shot was a success even though they only got something into orbit because we redefined what a moon shot was.


> isn't there for any kind of a long haul

That's a 'reasonable' cause for being short sighted, but it still means they are short sighted.


>"And if you're not hitting your targets, why, move the target! Imagine how much easier NASA's job would be if they could say the moon shot was a success even though they only got something into orbit because we redefined what a moon shot was."

This is the way in biomed:

>'When scientists finished the first draft of the human genome, in 2001, and again when they had the final version in 2003, no one lied, exactly. FAQs from the National Institutes of Health refer to the sequence’s “essential completion,” and to the question, “Is the human genome completely sequenced?” they answer, “Yes,” with the caveat — that it’s “as complete as it can be” given available technology.'

https://www.statnews.com/2017/06/20/human-genome-not-fully-s...


I wish this sort of knowledge transfer happened in teams more often.

Even in a relatively small team >20 I have found that even simple communication or sharing of knowledge falls apart _Very_ quickly.


It's something that you need to actively work on, just like automated tests. It also helps if you have someone who has written __good__ documentation before. The kind that people actually reference every few months.


My main thing is that I feel each person/role in a team should _not_ feel Siloed off from one another. That's how I constantly feel - not being included on email chains, meetings, or told thing of importance till the last minute.

Maybe I'm not actually supposed to be in the loop, but it still doesn't feel like how teams are supposed to be ran.


Mentoring programs, technical data packages (manuals and drawings for everything), a data repository (SharePoint), and a dedicated team of trainers.


>>> How do they do it in this day and age of "FAQs", "Forums" and "Helpdesks"? :)

The secret: Employee retention.

Everything is easier when the knowledge stays in the company.


Easier, yes, but that still doesn't solve the problem over the course of decades; in fact if that is your primary strategy, then you're going to be completely fscked as an organisation when someone _does_ leave (or dies). Employee retention might make things a little quicker to find, but is downright negligent as an institutional knowledge strategy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: