Category Archives: Uncategorized

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.

Shield

If you were to ask me who my favorite manager was, I'd say JA, my systems engineering manager on KEI at Orbital Sciences Corporation. She was my first manager, so it's difficult to say whether her ranking is due to her being my first manager (what do you compare it to?) or some sort of objective manager-ranking metrics (I don't know what these would be, but hopefully something near-sadistic like performance management reviews).

Anyway, I don't care why. I don't even remember the details. And the details I remember are through the eyes of an idiot.

The one thing I remember—or at least still feel—is the way she shielded the team from external bullshit. (Technical term.) I remember that. The project was receiving some non-negligible amount of chaos from the external environment, but I have this lasting feeling of how she absorbed much of that trouble, leaving the people on the team free to do the work.

More than a decade later: I would do a Bruce Willis barefoot walk over broken glass for that kind of leadership. It's hard. It's rare. It's valuable.

Why?

At least, why is it valuable? You hire people to do work—to develop software, to design gearboxes, to machine housings, etc.—not to debate, impotently, about some thing that they can't control coming down from some level that they can't affect. Boss's boss's boss wants some extra hot sauce on their status report? Or the resident subject matter expert wants three spaces after every period and a genuflection after every pronouncement? The people doing the work shouldn't be subjected to that kind of useless direction. Pass on the things that need to be passed on, but absorb the rest. It's a difficult thing to do to stand between the people who have the power and the people that are going to get rained unnecessarily on by that power.

If you want your people to get the work done you have to shield them from the environment when possible. Take the hit from the outside yourself, but do what it takes to let the people doing the work do the work.

Finite

Randomly—unexpectedly, that is, not everything you're not expecting to see is random, necessarily—some Finite Element came up in my music app.

Bring on the memories.

Finite Element was a band I played in when I was in college. Don't know what "finite element" is? Don't worry about it. Either you took that class sophomore year if you were an engineering student, or you didn't.

A long time ago—2008, we were just children then—I posted Finite Element's live show in 2003 on WEFT Sessions at 90.1 WEFT in Champaign. It contains, in song #7 "You Could Be Mine", my greatest bass riff, a... I'm not sure what it's called. I know in music there is a thing called a triplet, where there are three evenly space notes in two beats, but what I played was five evenly space notes in two beats. It's so subtle, so useless, and I'm so proud of it—it really tied the room together.

Never mind, never mind... the songs that came up weren't even from that radio gig. The songs that came up were from some demos we recorded in Sunil's apartment in 2003. Green Mars—Marte verde—Green Tuesday Records. I think I'll find all that I can, including set lists that I've saved in a folder (why?), for completeness, archive them here. I listened to the songs—more than once. The feeling that remains from that: I wasn't nearly as bad as I thought I was at the time I was playing the music. It's not great, but it's not bad. But I remember it being bad—viscerally remember it being bad. I still remember all the wrong notes. It's so weird. All the wrong notes... here they come... blarghmm... wrong notes.... I remember them all, like cuts directly to the psyche. But when faced with the same music unexpectedly, without being prepared to judge it, the right, or at least interesting, notes far, far outnumber the wrong notes.

How fallible, exactly, is memory? How much does the mind fixate on the wrong things versus the other things that weren't so wrong?

Let's steal some Kurt Vonnegut, from A Man Without a Country:

And now I want to tell you about my late Uncle Alex. He was my father’s kid brother, a childless graduate of Harvard who was an honest life insurance salesman in Indianapolis. He was well-read and wise. And his principal complaint about other human beings was that they so seldom noticed it when they were happy. So when we were drinking lemonade under an apple tree in the summer, say, and talking lazily about this and that, almost buzzing like honeybees, Uncle Alex would suddenly interrupt the agreeable blather to exclaim, If this isn’t nice, I don’t know what is. So I do the same now, and so do my kids and grandkids. And I urge you to please notice when you are happy, and exclaim or murmur or think at some point, If this isn’t nice, I don’t know what is.

Those songs on WEFT Sessions... that was right after I bought the fretless bass guitar... the one I sold in California in 2015... when I moved my wife to St. Louis when she went back to university and I stayed behind in California until I could find a job in St. Louis, and there wasn't really enough room for both me and the bass to sleep in the back seat of my car on weekends. I get really cranky about this, but no one knows, no one knows. She doesn't know—she doesn't know how I made the money stretch by not spending money, and she doesn't read these posts, and I can hide those facts here in plain sight. I think that's one of the sticky points when I think of that bass: pleasure and pain; confidence and unconfidence; certainty and uncertainty. I don't often think of that bass guitar, but when I hear the sounds, the unexpected doom doom doom sounds of the fretless, and the smooth sliding between notes... I miss it. I remember buying it with Sunil at Guitar Center in some Chicago suburb. I remember playing it. I remember relegating it to oblivion, an artifact from a prior life.

I still run meetings at work, as an engineer, the same way I used to take the microphone on stage as the bass guitarist, not the leader but the... person who could be counted on to take the microphone when someone needed to take it—for example, at The Embassy in Urbana in October 2003:

Finite Element at The Embassy

Again, I'll say: the most surprising thing about hearing our old music is that I wasn't as bad as I thought I was at the time.

What lessons could I learn from that?

What if...

What if the things I'm doing now—today—aren't as bad as I think?

And so what if the things we played were bad? Like when we played the Violent Femmes' "Blister in the Sun" at The Embassy, but the pace got out of control? So what? No humans were harmed in the making of these memories.

I want to find a lesson in all of this.

I'm not feeling much of a lesson, to be honest.

I can't remember how it all got started. Kevin and Sunil and I were all on the same aerospace engineering senior design team... and we played at a house party near where I lived at 5th and White in Champaign in... fall 2002? And where else did we play? The Illini Union. The Canopy Club. The Iron Post. The Embassy. The last week of Record Service (where is that copy of the Daily Illini with us inside the front cover?). Kams. Bits of the old website exist on the Internet Archive: feband.com. It's so weird, in far retrospect. It's almost like we were doing professional work, but I was fixated on the details, and I didn't really notice the big picture at the time. I was practically dying from lack of confidence, but the product spoke for itself. And what does that say about the things I'm doing today? Yesterday? Tomorrow?

Forget about the sun / For you're the only one / Who burns so bright

Rabbit hole: managing older employees

Offered, for the time being, without comment. But let's just say that, other than earlier this week running across a clip of Nirvana playing "Smells Like Teen Spirit" for the first time live in 1991, I've never felt more Gen X than I have in the past few weeks.

A week in review, 2019-W17

Wrote

None

Read

  1. Jason Kottke, Why Everyone Is Watching TV with Closed Captioning On These Days, kottke.org (2019-04-26).
  2. Joel Rose, Smells Like Teen Spirit,' The Anthem For A Generation That Didn't Want One, NPR (2019-04-23).
  3. Matthew Ehret-Kump, The American Spirit Behind China's New Silk Road, China Channel (2019-02-28).
  4. Andreas Klinger, Managing Remote Teams - A Crash Course, klinger.io (2018-12-10).
  5. Colin Dwyer, A Horrorshow Find: 'Clockwork Orange' Follow-Up Surfaces After Decades Unseen, NPR (2019-04-25).

Listened

  1. Americanish, Radiolab (2019-04-19).
  2. The Illiberal Turn: Shifting Geopolitical Alignments, Council on Foreign Relations (2019-04-04).
  3. #843 - Chemical Engineer Zips Up Solution for Baggy Shirts, Side Hustle School (2019-04-23).

Watched

Nirvana, "Smells Like Teen Spirit" (1991-04-17)

Upcoming


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