This is fantastic. I've just started skimming through these. As an orbit determination person, this one hits home (page 207). Thou shalt not do anything that is a maneuver without coordinating/informing the OD team.
"SUBJECT: Let 's have no unscheduled water dumps on the F ''mission
During a recerit Data Selection Mission Techniques meeting we were
informed that the CSM bas some sort of automatic water dump system.
It was even rumored that it might be enabled on the F mission while
the crew is sleeping during cis-lunar flight. This memo is to inform
everyone that an unscheduled water dump can really screw up M3FN orbit
determination. Accordingly, if we have a vote, this automatic capability,
if it exits, should be inhibited and water dumps should only be performe! as scheduled by MCC-H."
I’m just starting but there’s just so much to learn here and it scratches all the places where I have itches when it comes to complex project management.
There really is a subtle art to doing this kind of massive stuff that can’t be taught and just has to be experienced I think.
As I get older with more complicated projects under my belt, the one thing that continues to stand out to me as the difference between success and failure is a team with a well defined, common measurable goal and the freedom to experiment with solutions.
This means the key task is having a clear and measurable vision (the hardest part), building the team, resourcing it appropriately for the stage.
Bill Tindall clearly knew that and the process described here was basically him serving as a summary scribe to speed up communication between teams.
Seems simple and like what you would expect a technical leader to do, but in fact eludes most.
If I were to guess at the distinction or genius or whatever you’d want to say that Bill Tindall brought to the process, it was identifying wheat from the chaff as the people closest to the problem are throwing around grains. Its hard to define granularly, but being able to compress loose ideas into something coherent with a consistent trajectory is a skill that can be learned to a degree but I find that its rare enough that it must be to some extent biological.
The Moon Machines episode "The Navigation Computer" focuses a bit on Charles Draper's system based on gyroscopes and accelerometers. The show includes a segment on the software-development issues that led to Tindallgrams. I never thought to look them up. Thank you.
These are wonderfully clear and (would have been extremely) useful. It’s hard to imagine how I would keep notes on a 12 hour meeting and then produce such thoughtful notes overnight to guide the next day’s discussion.
Aspirational, but perhaps easier since I’ve now seen that it can be done.
Somewhat related: why was software known as "data priority" in the Apollo program? (Tindall himself was the chief of "data priority coordination" which really meant getting all the software people aligned to a common schedule and integration platform – i.e. "software coordination".)
I don't know the true answer, but from what I understand, one big reason they brought software onto the spacecraft to begin with was to be able to work with input streams from all the redundant sets of sensors they had. Making sure a healthy input stream was selected as the primary data source at all times was t known as the "data priority problem", and software was a big part of how it was to be done.
