Author Archives: kirk.kittell

Hysterical and useless

This song popped up on a random play of my entire music library today, and it surfaced some memories with it: Radiohead, "Let Down", OK Computer (1997).

Mostly I remember it because I would sing the lead part during the bridge, and Sunil would sing the harmonies—although I only specifically remember playing it at The Embassy in Urbana in 2003, we might have played it elsewhere.

I also remember it because of a few recurring lines that have always stuck with me, for whatever reason:

One day
I am gonna grow wings
A chemical reaction
Hysterical and useless
Hysterical and useless

I don't know what Thom Yorke intended with that. I don't always know what I take from it. "Hysterical and useless" sounds bad, in isolation—but isn't that how you could describe all of our flights from who we are and what we are? To some extent, don't you really have to reach beyond your grasp to become something new, something different?

A week in review, 2019-W26

Wrote

  1. Control (2019-06-25).

Read

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

Listened

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

Photo

Nxt@4240

Upcoming


There might be additional links that didn't make the cut at notes.kirkkittell.com

A week in review, 2019-W25

Wrote

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

Read

  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.

Listened

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

Watched

Sex Education (2019)

Upcoming


There might be additional links that didn't make the cut at notes.kirkkittell.com

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

Wrote

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

Read

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

Listened

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

Watched

Murder Mystery (2019)

Upcoming


There might be additional links that didn't make the cut at notes.kirkkittell.com

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

Wrote

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

Read

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

Listened

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

Watched

Capernaum (2018)

Upcoming


There might be additional links that didn't make the cut at notes.kirkkittell.com