This is sad, scary, and as far as I've seen an inherent part of any long running engineering project. As software developers, we have a hard time understanding the rationale of some of the code we wrote last week, let alone someone else's code from a year ago (I don't want to imagine any of my company's code running 30 years from now!).
In a recent series of design meetings I was running for a large project, I started to tackle some of these problems by emailing out the final decisions we had made at the end of each meeting. The following week we'd still have problems in understanding/remembering the chain of arguments that led to the final decisions, and we'd lose some time re-tracing our steps. So I then adjusted to not only summarizing the decisions at the end of each meeting, but noting step by step the arguments/debates that led to it. Then at the beginning of each meeting I'd review them to the group. This worked, but it was an awful lot of note taking.
I almost wonder that now that more and more of these discussions are done through work email, IM, version controlled documentation (and code), the job of future archaeologists will be much more manageable (though still hard and fraught with risk). Maybe more and more tools will develop to piece together a project's evolution, rationale, and implicit assumptions and decisions.
The problem with going through people's old email and such is the signal/noise is extremely low, and often of a timely nature, and may not represent the final outcome, especially if work has been done on a system after the fact.
What we need is testable documentation. I do IT work most of the time, and document using a mashup of Markdown and text snippets in a specific format for network documentation, all kept in version control.
I then have a motley collection of scripts and tools that run against my text files and do simple testing like pinging all the hosts mentioned, checking DNS entries, etc. Frequently I'll write up docs before I start work, then by the end of work, all the tests will past. It's TDD applied to network design.
I almost wonder that now that more and more of these discussions are done through work email, IM, version controlled documentation (and code), the job of future archaeologists will be much more manageable (though still hard and fraught with risk). Maybe more and more tools will develop to piece together a project's evolution, rationale, and implicit assumptions and decisions.
It's funny, Wave was actually a really fabulous tool for exactly this.
We aim for self-documenting code. If there is a decision that absolutely can not be reflected in the code itself, a comment goes with the code as close to where the decision is implemented as possible.
We have a 10-year-old code base that is doing well and continues to support rapid, robust and maintainable development. The learning curve is higher than if the documentation were external to the code base and accurate diagrams existed, but unlike those artifacts the code will always be right about what the code is doing.
In a recent series of design meetings I was running for a large project, I started to tackle some of these problems by emailing out the final decisions we had made at the end of each meeting. The following week we'd still have problems in understanding/remembering the chain of arguments that led to the final decisions, and we'd lose some time re-tracing our steps. So I then adjusted to not only summarizing the decisions at the end of each meeting, but noting step by step the arguments/debates that led to it. Then at the beginning of each meeting I'd review them to the group. This worked, but it was an awful lot of note taking.
I almost wonder that now that more and more of these discussions are done through work email, IM, version controlled documentation (and code), the job of future archaeologists will be much more manageable (though still hard and fraught with risk). Maybe more and more tools will develop to piece together a project's evolution, rationale, and implicit assumptions and decisions.