Tindallgrams

In an earlier HN discussion someone asked for specific Tindallgrams of interest. I wrote up a summary on the greatest one I've found: https://two-wrongs.com/tindall-on-software-delays.html

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."

This is absolutely fantastic!

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.

https://youtu.be/6syfevpG-1U?t=1410

Related:

Tindallgrams - https://news.ycombinator.com/item?id=17685247 - Aug 2018 (13 comments)

Tindallgrams: Crowdsourced effort to preserve NASA spacecraft software memos - https://news.ycombinator.com/item?id=10204108 - Sept 2015 (1 comment)

Recommend https://sunburstandluminary.com/SLhome.html for more context. Fun read.

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.