Category Archives: Uncategorized

The ritual of the notes

At work I'm fairly methodical about planning ahead for the next day, week, month--almost as methodical about planning as I am about disregarding the plan when the time comes. It involves OneNote and I should explain it sometime--it's a useful system.

One key part of it is making a new note page for every (pertinent) meeting in my calendar. It serves two purposes: (1) to line up the day's or week's events; (2) to catch notes from the meeting. The first part I'm good at; the second part I'm not.

I think that a slight frame of reference shift would improve the actual keeping of notes. I tell myself: it's about the information. It's about keeping receipts. It's like an old school engineering lab notebook. (A fine ritual itself.) But I don't think that's the most useful thing. The notes themselves aren't as important as the ritual of the notes. Why don't I write meeting notes as frequently as I think I should? Can't keep notes when you're not paying attention. Can't keep notes when you're talking too much (or doing that thing where you're just waiting for an opening to talk). Being present in that moment is the real value.

I am good at keeping notes when I am or feel responsible for keeping notes for the group in a meeting. Perhaps tapping into that is another method to self-motivate.

Metrics and their discontents

A fair amount of my job involves figuring out how to collect some data about work processes and... well, just packaging it in a table or chart so that managers can, presumably, use it to make decisions. Sometimes it's interesting because you have to get down into the esoteric nuances of the definitions involved in the data, debugging things along the way to get the data right and the right data. Most of the times it's just work.

But sometimes there's a little itch in the back of my mind that seems to indicate: maybe we don't need to do this. Or: maybe we're not measuring this right and someone who isn't us, whose work we're overseeing, is going to pay for it. Or: aren't we just expressing the same measurement in three different ways that say the same thing. And so on.

Measuring work is somewhat enjoyable, in the sense that you and your team can get better at what you do, but the time spent doing the measure sometimes also unironically eats the time you would spent doing what you do, which drives an unironic feedback loop of more measurement, less doing. It's frustrating.

There's an art involved in selecting what to measure, how to transform it, how to show it, who to show it to, how to use it, etc. I'm not an expert. But I think the most important question is: how am I going to use this? If the measurement doesn't have a specific use, throw it out. Go lean. Collecting for the sake of collecting is a disorder--hoarding. Side effects include: what's measured gets managed, even the data you collected that doesn't have a specific useful purpose. Don't believe it? Hand your boss a chart with a downward-pointing graph. Exchange your dignity for a few action items.

Fuzzy ideas, fuzzy ideas... I can't quite put my finger on what I think the problem is. In the meantime, a reference that for me has turned into a source of references, and a comfort when I think I'm the only person wondering why I'm carrying this bag of numbers around everywhere: Jerry Muller, The Tyranny of Metrics (2018) (notes).


It's just as well that I haven't read David Foster Wallace's A Supposedly Fun Thing I'll Never Do Again, because this presentation I gave last week on lessons learned from the excesses of running 100 miles in a past life would have been besotted with footnotes.

(Pause to read: David Foster Wallace, "Shipping Out: On the (nearly lethal) comforts of a luxury cruise", Harper's Magazine, Jan. 1996.)

For our MGT 5315 Leadership Communications I class, we were instructed to give a 4-minute "TED" talk to the class about... actually I didn't read the assignment, so I'm not 100% sure what the framework was. But: 4 minutes. Essentially nothing. The question for me was: should I recycle the Apollo 11 presentation I gave over the summer at Venture Cafe? Or go for something different.

Let's talk about a supposedly fun thing I'll never do again: running the Western States 100.

Honestly: 4 minutes isn't enough to say anything about anything, so I just pulled together a few lessons learned from the race, then threw some away, pared it down some more, then let 'er rip.

It's no good posting my slideshows here (eh, pdf, here you go) because I do what I think any humane person ought to do: rip out the content like old wallpaper. It's an experience. You've got to be there. It requires gaging the audience like a barometer, then—somehow—adjusting the talk as it goes. Each audience environment comes with its own terrain, and if you can feel the contours of that terrain you can find different approaches to where you want to go—you can even find different places to go. I don't understand it. It's some alchemical process that transforms anxiety into rocket fuel.

I very much enjoyed telling a story that I never get to tell. (#2: F*** gear.) Somewhere around mile 15 or 20 or so, someone who I was passing, one of the multitude who confuses the things you run with and the run itself, asked about my shirt:
"Is that a cotton shirt?"
[long pause]
"Is that OK?"

The best part is the deke at the end. Start off with some high quality TED-cult content (#6: Don't quit)—which is all very well, good advice, etc.—and then waiting until the audience leans that way and edging it back for the score (#7: Quit). Which, by the way, is better advice. How many people in the world give you the "never give up" speech without any context whatsoever? These people don't have your best interests at heart. I only dropped out of one race, the 2012 Ozark Trail 100, at mile 50, though if ego hadn't gotten in the way I would have dropped out when I should have at mile 37, saving myself weeks of recovery on a bum leg. Never quit. No. Never never quit. Quit in context. Live to fight another day.

Sit back, relax, and enjoy the flight

Flying is de rigeur now. Has been. I don't notice so much the outside of the plane--the environment through and over which we're hurtling. No more counting grain elevators until they're flat with the perspective. No more noticing the creeks and rovers like fire as they briefly reflect the sun. No more naming the features down below. Looking out the window, when it happens, is just to watch the flight surfaces trim slowly back and forth. (Until it's speed brake time.)

It's all still there if you want it. The magic or wonder of those first (many) flights isn't really replaced by anything. Flying is now just the simple subtraction of distance. Step in a tube on one side in St. Louis, step out the other side in Shanghai--an ellipsis in between. It's still about sitting back back, maybe a little more relaxing, but a little less enjoying the flight.

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?

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.

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

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.

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.