Monthly Archives: June 2019

A week in review, 2019-W26


  1. Control (2019-06-25).


  1. Luke Halliwell, The Agile Disease, Luke Halliwell's Weblog (2008-11-16).
  2. John Herrman, Slack Wants to Replace Email. Is That What We Want?, The New York Times (2019-06-19). For employees raised online, Slack looks and feels like a place to socialize. I grew up chatting with friends online and still do, sometimes in scattered Slack rooms. I have also spent the last 10 years at companies where work chat was the norm and observed the arrival of Slack with both relief and suspicion. Finally, a better work chat app. Then: Oh god, this is really how people are going to work, now?
  3. Zachary Crockett, The restaurant owner who asked for 1-star Yelp reviews, The Hustle (2019-06-09).
  4. Konstantin Kakaes, What Neil Armstrong Got Wrong, MIT Technology Review (2019-06-26). The Apollo program failed to make such a leap. Its success was in taking the technology of the time as far as it could go, just as the pharaohs built the absolute biggest pyramids they could. It was a monument to ingenuity and to determination. But monuments are, by design and by definition, ends and not beginnings.
  5. Derrick Goold, A scout, a backup catcher, Pujols & the trade that would have changed Cardinals history, St. Louis Post-Dispatch (2019-06-22).


  1. A Mathematician Translating Pushkin?, Math Mutation (2019-06-23).
  2. Umbrella Revolution 2.0 – or something else? Antony Dapiran on the Hong Kong demonstrations, Sinica Podcast (2019-06-27).
  3. 644: Random Acts of History, This American Life (2019-06-23).




There might be additional links that didn't make the cut at

A week in review, 2019-W25


  1. Systems engineering and agile (2019-06-18).


  1. Steve Demming, Understanding Fake Agile, Forbes (2019-05-23). Judging from the examples, it appears that "Agile lite" means the adoption of tools and practices of Agile without necessarily deploying them with an Agile mindset. Without an Agile mindset, Agile remains an inert, lifeless set of ceremonies.
  2. Keith Collins, The code that took America to the moon was just published to GitHub, and it's like a 1960s time capsule, Quartz (2016-07-09).
  3. James Pollard, Found in a High School Restroom: Cache of 1940s Wallets and Their Contents, Riverfront Times (2019-06-21).
  4. Kuʻuwehi Hiraishi, Makaliʻi: Sustaining A Voyage Solely On Locally-Sourced Food, Hawaii Public Radio (2019-06-13).
  5. Neil Thomas, The Politics of History: Why Anniversaries Matter in China, MacroPolo (2019-06-18). Placing symbolic weight on historical anniversaries is a double-edged sword, however. In non-democratic polities where the government dominates public discourse, political activists often appropriate official commemorations to express dissent or mobilize protest, as such events provide a sanctioned veneer that can restrain or delay government responses. Historical anniversaries also serve as "focal points" for collective action because they help protestors overcome the coordination problem posed by state gags on unapproved information.


  1. Bit Flip, Radiolab (2019-05-08).
  2. CHP-223-The History of Tang Poetry Part 6, The China History Podcast (2019-06-02).
  3. Podcast #517: What Big-Time Catastrophes Can Teach Us About How to Improve the Systems of Our Lives, The Art of Manliness (2019-06-17).


Sex Education (2019)


There might be additional links that didn't make the cut at

Systems engineering and agile

A few weeks ago, the INCOSE Midwest Gateway Chapter (the local professional society for systems engineers) hosted an event called Agile in Systems Engineering. Basically, I begged one of our directors, Adeel, and one of our best members, Matt, to explain to systems engineers what the hell agile development is. Whether it's a fad or not doesn't matter. If you're going to be exposed to it, you should know more about it. Even if it is a fad, you should steal the good parts mercilessly and incorporate it in your repertoire.

Systems engineering and agile development (agile software development, at least) are fundamentally opposed. We're not supposed to say that out loud, but it's true. Systems engineering is largely a top-down decomposition from what a customer wants to how a system should satisfy that to how subsystems should support the system, and so on. It's about definition and control from the top. Agile is more about bottom-up. Develop the system by developing the system—develop the system (software) by doing it, and respond to changes as they come.

The problem is not that there is one idea or the other but, inevitably, when a top-down organization wants to incorporate agile or a bottom-up organization wants to incorporate systems engineering, there is capital-P Pain.

I am living in capital-P Pain.

The purpose of my life at work right now, as a systems engineer in an organization that wants to pursue agile software development in an environment of top-down control, is to serve as a kind of buffer. On one hand, I'm trying to be a buffer to block the software developers—the people actually doing the work—from the vagaries of the people who own the project schedule. (See also: Shield.) Agile is, in very rough terms, about establishing a backlog of work that needs to be done for a project, and then selecting the most important bits of it that can be done in a sprint (two- or three-weeks). As the people up high want to shift the schedule, they lose patience with the priority of the backlog and the sprint, and they (naturally) want to adjust it. But that's not allowed. Make a plan and stick to it.

On the other hand, I'm trying to be a buffer to block the specific details of what the developers are doing from the managers. If you try to say specifically that today was a slow day and yesterday was a slow day because the work being done is subtly difficult, the top-down managers only see a blinking red neon sign that says LATE. So it takes some finesse to translate the work being done, or the preparation for the work being done if there aren't any discrete accomplishments, to keep the managers from bothering the developers to death.

So a lot of working as a systems engineer in an agile environment—an agile environment in a large organization used to top-down control, at least—is about acting as a translator between two fundamentally opposed paradigms. It's thankless work of questionable utility. It takes a lot of time and effort to translate schedules and still, at the end of the day, some joker will come up and ask you: why aren't your requirements done yet?

So I'm thinking to submit an abstract to the 2019 INCOSE Great Lakes Regional Conference (call for submissions to talk about this. Many people, in my opinion, spend their time in top-down or bottom-up jobs, so maybe it's time for somebody to provide some kind of Rosetta Stone to link the two together. At the very least, it might cause me to crystallize some things I do in my day-to-day work. Stay tuned, etc.

A week in review, 2019-W24


  1. Landing on the moon: three visions attained (2019-06-10).
  2. Now reading: Moon Lander: How We Developed the Apollo Lunar Module (2019-06-11).
  3. Now reading: Digital Apollo (2019-06-15).


  1. Robert McMillan, Her Code Got Humans on the Moon—And Invented Software Itself, Wired (2015-10-13). For Hamilton, programming meant punching holes in stacks of punch cards, which would be processed overnight in batches on a giant Honeywell mainframe computer that simulated the Apollo lander’s work. “We had to simulate everything before it flew,” Hamilton remembers. Once the code was solid, it would be shipped off to a nearby Raytheon facility where a group of women, expert seamstresses known to the Apollo program as the “Little Old Ladies,” threaded copper wires through magnetic rings (a wire going through a core was a 1; a wire going around the core was a 0). Forget about RAM or disk drives; on Apollo, memory was literally hardwired and very nearly indestructible.
  2. Dick Day, Training Considerations of the X-15 Development, NSIA Meeting (1959-11-17). In: Gene Waltman, Black Magic and Gremlins: Analog Flight Simulations at NASA's Flight Research Center, NASA SP-2000-4520 (2000).To train the pilots for the X-15 landing phase, several methods were considered. First, an analog computer was used with an oscilloscope presentation to indicate approach attitude. This gave the pilots and engineers an understanding of the relative importance of the factors affecting the landing flare, but definitely lacked the in-flight realism afforded by the rapid approach of the ground.
  3. Margaret Hamilton, Computer Got Loaded, Datamation (1971-03-01). To blame the computer for the Apollo 11 problem is like blaming the person who spots a fire and calls the fire department. Actually, the computer was programmed to do more than recognize error conditions. A complete set of recovery programs was incorporated into the software. The software's action, in this case, was to eliminate lower priority tasks and re-establish the more important ones. The computer, rather than almost forcing an abort, prevented an abort. If the computer hadn't recognized this problem and taken recovery action, I doubt if Apollo 11 would have been the successful moon landing it was.
  4. Patrick Burke, When the River Took John Squyres, Outside Magazine (2019-02-28).
  5. James Scott, Aftermath: How the Doolittle Raid Shook Japan, World War II Magazine (2015-06-01).


  1. 676: Here’s Looking at You, Kid, This American Life (2019-06-02).
  2. The Inca, In Our Time (2019-06-13).
  3. A student leader 30 years after Tiananmen: Wu’er Kaixi reflects on the movement, Sinica Podcast (2019-06-13).


Murder Mystery (2019)


There might be additional links that didn't make the cut at

Now reading: Digital Apollo

David Mindell, Digital Apollo: Human and Machine in Spaceflight (2008). (Goodreads/review - notes)

I found this book while searching for more information about the Apollo Guidance Computer in preparation for a talk (see: Landing on the moon: three visions attained). Fortunately for me, the nearest St. Louis County Library branch to work had a copy.

I had assumed the book was just about the computer itself, which was why I got it, but at ~80 pages in, it really hasn't been covered except by reference. Instead, what the book has covered is something that I recognize from developing flight controls back at Mason, and to some extent in systems engineering in my current position: the tension between the human pilot and the automatic pilot (and by extension its designers). It's an inevitable tension—in simplistic ego terms, the fight between controlling and being controlled. In more sympathetic terms: it takes more than equations to design and more than human experience to fly a sufficiently complex aircraft.

So: straight ahead, learning more about X-15, etc., until I get to the parts about the AGC and flight software that I wanted to learn more about. In the meantime, the book has also been the source of some interesting citations:

[p. 73] In those days, airplanes were unreliable and I thought they might become more so. I never flew without a pair of pliers, a screwdriver, and a crescent wrench in pocket so I could fix things on the airplane. This was being a mechanic, not an engineer. I had applied for the Engineering School because I thought there should be a better rapport between the aeronautical engineer and the pilot. It seemed to me that the engineers felt pilots were all a little crazy or else they wouldn't be pilots. The pilots felt the engineers as a group were, if not incompetent, at least not thoroughly acquainted with the pilot's viewpoint—that all the engineers did was zip slide rules back and forth and come out with erroneous results and bad aircraft. I thought from a philosophical point of view that it would be good to have engineers and pilots understand one another better. It seemed desirable to marry these two capabilities in one person—and I wanted to be that person.

—General Jimmy Doolittle, I Could Never Be So Lucky Again: An Autobiography (1991)

To train the pilots for the X-15 landing phase, several methods were considered. First, an analog computer was used with an oscilloscope presentation to indicate approach attitude. This gave the pilots and engineers an understanding of the relative importance of the factors affecting the landing flare, but definitely lacked the in-flight realism afforded by the rapid approach of the ground.

—Dick Day, Training Considerations of the X-15 Development, NSIA Meeting (1959-11-17). In: Gene Waltman, Black Magic and Gremlins: Analog Flight Simulations at NASA's Flight Research Center, NASA SP-2000-4520 (2000).

Now reading: Moon Lander: How We Developed the Apollo Lunar Module

Tom Kelly, Moon Lander: How We Developed the Apollo Lunar Module (2001). (Goodreads/review - notes)

Naturally, when faced with the opportunity to dig into the Apollo program, I came back to this book, which I haven't read since... sometime in college, I don't even know when. Whenever anyone asks about a good systems engineering book, this is the one that I suggest—it's just a wonderful design effort to meet a set of gnarly and shifting mission requirements in a previously untried environment. It would have been an incredible opportunity to be on that program. Just... amazing.

[p. 51] I had the aerospace engineer's dream job of the century. Not only would I design and build the first spaceship to land men on another heavenly body, but I was encouraged by NASA to let my imagination run wild and question everything we and they had done in prior studies and the LM proposal. I could start fresh, with a clean sheet of paper, using our past work as a point of departure. Such freedom!

What I remember liking about this book is that the program it covers, the development of the Lunar Module at Grumman in the 1960s, is not at all smooth. Things are late, things don't work, things break, the customer changes their mind, etc. It's all stuff we have to deal with today, sure, but the stakes were really high and public, and the mission was literally and figuratively out there.

I don't often re-read books, but I'm really looking forward to reading this one again.

Bonus: here are some papers by Tom Kelly that discuss the history of the Lunar Module.

Kelly, Thomas. "Design features of the project Apollo lunar module (LM)." 16th Annual Meeting and Technical Display. 1981. doi: 10.2514/6.1981-910.

Kelly, Thomas. "A review of the Apollo Lunar Module program and its lessons for future space missions." Space Programs and Technologies Conference. 1990. doi: 10.2514/6.1990-3617.

Kelly, Thomas. "Manned lunar lander design-The Project Apollo Lunar Module (LM)." Space Programs and Technologies Conference. 1992. doi: 10.2514/6.1992-1480.

Landing on the moon: three visions attained

A follow-up to: Systems engineering and Apollo

The trouble of talking about the Apollo program, without resorting to tropes—redacted comments about how the same people who brag about being able to design things to land on the moon when they were in their 20s with no experience whatsoever are the same people who require you to go through twelve reviews to publish a test plan that they still have veto authority over if it passes—is that there are still a million things to cover.

I think that if I do go ahead and give this talk in July that I would focus on the landing. I got some interesting feedback about mission design and about the Saturn V rocket, but it's still the landing that most captures my imagination. My parents gave me a copy of Tom Kelly's Moon Lander: How We Developed the Apollo Lunar Module (2001) (notes) sometime when I was in college, and I still offer that book as an example when people ask for a book about systems engineering. The book even mentions systems engineering by name, which I didn't realize until I was reading through it again (I wouldn't have known what that meant in college anyway, though that matches fairly closely what I was doing on projects, etc).

"Three visions attained". That idea is ripped off from an interesting New York Times Magazine article about Robert Moser Neal, Frank Lloyd Wright, and Alex Jordan Jr: "Wisconsin: Three Visions Attained" (1993-03-07). It's a good article—read it. I like it because (1) I lived in the Driftless Area for a while, (2) The House on the Rock is one of my proto-memories from summer vacations while growing up, and (3) for reasons I don't understand Frank Lloyd Wright is a Midwesterner who is To Be Revered As A God. Just read it.

I don't even care if I give a talk or not. Just thinking about it, and organizing my thoughts, is a kind of love letter to the idea of space travel that has more-or-less been shelved. So be it.

But: landing on the moon. What would the three visions be?

The first one is easy: Tom Kelly—the guy in charge of the Lunar Module program at Grumman. So: talk about the design of the Lunar Module.

The second one also presents itself: John Houbolt, the chief instigator of the Lunar Orbit Rendezvous mission mode of landing on the moon.

And the third one? Open.

The temptation is to dig deep into something esoteric. Space suits. Display panels. Apollo Lunar Surface Experiments Package (ALSEP). Software... bingo. Maybe it's a good place to talk about Margaret Mitchell and the flight software on the Apollo Guidance Computer.

A week in review, 2019-W23


  1. Systems engineering and Apollo (2019-06-24).


  1. John Logsdon, Selecting the Way to the Moon: The Choice of the Lunar Orbital Rendezvous Mode, Aerospace Historian (1971-06-01).
  2. Mark Alan Stamaty, The Corner of 'MacDoodle St.' and Memory Ln., The Paris Review (2019-04-04).
  3. Mike Hurtt, Mac's Wild Years, Ponderosa Stomp (2019-06-07).
  4. W. Pate McMichael, Losing the Moon, St. Louis Magazine (2006-06-28).
  5. Mary Laskowski, Discovering treasures in Library’s storage vaults, Illinois News Bureau (2019-05-30).


  1. Live Episode! Tofurky: Seth Tibbott, How I Built This (2019-06-03).
  2. 155 - Live in New York - Post Truth, You Are Not So Smart (2019-06-03).
  3. Preparing for the next recession, The Brookings Cafeteria (2019-05-24).


Capernaum (2018)


There might be additional links that didn't make the cut at

Systems engineering and Apollo

Follow-up: Landing on the moon: three visions attained

This summer will be the 50th anniversary of the launch and landing—and launch and landing—of the Apollo 11 mission to the moon. At the risk of sounding morbid: it will be the last major anniversary of the event that will be attended by any of the original participants. Maybe the great-grandchildren will celebrate the 100th anniversary.

So if you want to throw a party to celebrate Apollo, the time is now.

I wasn't thinking of the anniversary myself. I got a note from the NASA JPL Education Office email list (join) about using the anniversary to teach kids about the moon (Celebrate the 50th Anniversary of NASA's Apollo Moon Landing with Educational Resources and Projects for Kids). And we were looking for something to do for our local systems engineering professional society, INCOSE, anyway. So I opened my big mouth and volunteered to give a talk about Apollo and systems engineering.

I don't know exactly what I'll talk about. There's too much to talk about. Project Apollo was an enormous engineering project with many, many different subprojects and systems and interfaces and so on—an enormous number of starting points from which to explain the project in terms of systems engineering, so it's hard to limit myself to just a few. Also, I haven't thought about spacecraft of any kind in years, having nudged myself out of an orbit where I got to work on space projects into, well, several orbits that don't, so my understanding of the concepts involved are a little rusty.

Anyway—problems and opportunities. Learn something, teach something. Get excited by something, throw a big party.

I know vaguely what the format will be. I want to pick three or four topics or episodes or players and present them as vignettes. Instead of trying to paint the entire picture of systems engineering in Apollo, I want to paint just a few bits in detail and give a map to the audience to find the rest. Here are a few interesting topics that I think I can be explained, in too much detail, in systems terms:

  • George Mueller and "all-up testing" of the Saturn V rocket
  • Tom Kelly and the moon lander (#NowReading: Moon Lander: How We Developed the Apollo Lunar Module)
  • Joseph Shea and systems engineering management
  • John Houbolt and lunar orbit rendezvous
  • The Apollo Guidance Computer

That's a short list, but each topic quickly goes fractal and then there's too much. So access to materials and finding unusual angles will determine which few things to talk about.

In the meantime, as I'm tracking down references, I'll add a page here to collect it: /ref/apollo.