I got really pumped up to die on this hill (again) today, but managed to back off at the last minute. It might be aerospace or technology esoteric, it might not be—I don't know.
"More rigor" does mean "more process". And "more process" does not mean "more rigor".
I worked ever-so-briefly in a software quality assurance organization with some respectable and respected engineers. Here's what happens when you value—abstractly value—process: you get more process. My analogy for it was always something like this. What does Lebron James get paid for? Making more baskets. What do process engineers get paid for? Making more processes.
More process works for a while—until it doesn't. There's a sort of inverted-U of usefulness. There's Wild West on the left side where you're just slappin' things together—great for the garage and the protoshops, less so if you want build things that people use, especially to put themselves in at tremendous speeds and altitudes. There's total lockdown on the right side where you don't move don't think don't breathe don't achieve .
The sweet spot is there in the middle somewhere. It's never a stable optimal point—the people change, the technologies change, the requirements change, the certification authorities change, your understanding of the problem will change, and so on. But the answer is not more unless you're flat-out missing things. In fact, as you add more, you are at some point begging for steps to be missed or mangled, for process steps to fall behind reality, for malicious compliance out of frustration.
I have achieved my [checks notes] only stay-at-home accomplishment so far: made it to the top league in the weekly leaderboard on Duolingo (kirkkittell).
As I've mentioned somewhere around here, it hasn't been easy to focus the last few months. That's hardly a controversial thing to say—is anyone focusing? Send detailed instructions if you are. I don't know how people with kids are managing it. Running through a few lessons on Duolingo in the morning is one of the few things I've been consistent about—I'm on a 102-day streak now. I've been slowly walking up weekly running distance to 30 km/week and pushups to 220/day—bumping them up every week (recently) by 5 km/week and 10 pushups/day. The increase will eventually collapse under its own weight, but in the meantime I'm trying to grab onto the things that I can and fix them in place, then build something around them.
There is a feeling of the days being lost to routines like this—do this in the morning, do that after work, do this before bed, repeat repeat repeat repeat, where did the month go? However. I've lost plenty of days to irredeemable low spots, so if Chinese lessons and running and pushups keeps the world on track, I'll go with it.
The latest one involves turning scrap wood reclaimed from a barn in the forest into a fence around a pond, breaking rocks to repair the top level of the pond, planting hundreds of seeds and starting them in a greenhouse (a self-made greenhouse, but there's really no reason to point that out because everything on this channel is self-made, and it's almost jarring when something pops up that isn't self-made, like the drill used to set the wedge in the rocks), then screencutting through a few seasons to show the seeds becoming seedlings becoming fruit-bearing plants, and the fruits and vegetables and leaves and seeds being turned into several courses of food.
I could do that.
[sip some water]
[look nonchalantly away from the screen and notice something else in the room, anything else in the room, hoping no one saw me having that thought, because it's the kind of thought that should result in an action or, in the case of Li Ziqi, should result in about 40 actions, many of them chained together but in overlapping sequences that cover minutes and hours and days and seasons]
There is—scarequotes inbound—"more time" now because I don't have to drive to work. There should be time available to start, execute, and finish projects at home. Where does that time go?
Ah—that's the wrong question.
Thoreau, Walden, "Excursions": "As if you could kill time without injuring eternity."
It comes down to principles—... I'm not sure how to finish that one. The principle isn't about filling the time, or about Getting The Most Out Of Your Life, or... I'm not even sure it's about principles now. It's just fun to have ideas and make them real. It's not fun to infinitescroll through social media—you get the dopamine while doing it, which is like fun I suppose, but then the shame hangover, which is certainly not like fun. It's more comfortable to stay inside than to go outside where it's hot and humid; it's more comfortable to stay inside and read some junk articles and to stay inside and finish calculating the material list for the backyard steps.
What to do about it is obvious. Decide to do what needs to be done, and do it. There is no magic.
Ever since classes went fully online in the spring semester, I've had a horrible time concentrating during lectures. There's the usual self-caused distractions—the phone, the browser, literally any other room of the house besides the one with the lecture playing—but even when I'm there, trying to focus like a Good Boy, it's really hard to lock in and take something from the class. Since the classes are three hours long, only twice a week, it's a real grind trying to force focus. Don't look to me for advice on how to do it.
Except today—I tried something accidentally. In the finance class we were doing some calculations on bond values, and I went to Excel like I normally would for calculations. And we occasionally needed to shift the term length on the bonds, and calculate the annual value like we would on a timeline, and Excel was just feeling a little too stiff—changing the number of rows or columns or whatever on the fly, manually. And I was focusing that great anyway, so I popped open Eclipse and started trying to create the calculations in Python instead.
I never really got the thing to do much yet (finance_sandbox.py) but there was a different kind of focus that set it once I started doing it. Setting up classes and thinking about what attributes of the bonds I had to capture from the lecture, trying to quickly think of abstractions so that I could calculate problems with different features from the lecture—having to create and re-create the most basic aspects of the things we were learning about turned out to be very helpful.
I just finished Chapter 7 of this book, which used the F/A-18E/F program—from ol' McDonnell right here in St. Louis—as a case study for how to integrate project management and systems engineering via integrated product teams (IPTs). I've never really thought much about the whys and wherefores of IPTs. They're just part of the air that you breathe on large aerospace/defense programs, projects decomposed into functional teams and subteams and so on. I wasn't sure if IPTs are still in style or not—I think we're all agile now—but clearly aerospace companies are putting that in their job postings, so it must still have some currency.
Anyway. You either have access to that book or you don't. But it is drawn heavily from other references that are readily available. If F/A-18E/F is as good of an example of how to integrate systems engineering and program management as the book describes it—ahead of time, under budget, under weight (in a good way)—then it's something worth learning more about, to see how they did it.
Bailey, E., Nash, S., & Woolsey, J. (1999, January). Integrated product and process development case study, Development of the F/A‐18E/F. Institute for Defense Analyses. IDA D‐2228. https://apps.dtic.mil/sti/citations/ADA379633
"Ce qui vaut la peine d'être fait vaut la peine d'être bien fait". ("What is worth doing is worth doing well".) You've heard that one before. That's just a gateway drug, though. Doing something well leads to wanting to understand the patterns and causes and then, once you can start to get a grip on the classes and methods of that something it's only natural to want to start building a machine of some sort to do that something for you.
(I'm saying "you" but I know I'm thinking "me". Bear with me on this one. I need to talk about this like it's your problem. It's easier to deal with, etc.)
My big Home Project now is building some steps from the back door of the garage down to the back yard—the Backyard Steps Project. In isolation: it's not that difficult of a problem.
My wife would also like the backyard to be leveled—the Backyard Leveling Project. In its current state (which I was tempted to call its "natural state", although this would be a casual lie because it was certainly modified during the installation of these suburbs in the ~1960s, and perhaps even before that, I don't know) there is a downslope from north-to-south and from west-to-east. As the proud owner of a shovel (a collection of shovels, really, don't judge), the solution to the leveling problem is simple: take a shovelful of dirt from the high side and put it on the low side. Repeat until there is no high side or low side.
Simple specification, simple implementation. I'd crawl on my knees and beg for a spec to be this easy to implement at work. However, there is some coupling between the Backyard Steps Project and the Backyard Leveling Project that is giving me a headache.
How many steps does one need? Assuming you care about your user (you should—I do), the steps should be an equal height—an obvious assumption, sure, but we're just building out the model here. Now you have h_step, and n_steps * h_step will be the total elevation change (h_total) from the landing at the top (z_top) to the landing at the bottom (z_bottom); or, in reverse, the total elevation change will give you n_steps, just divide h_total by h_step. z_top is fixed—the garage slab is not going anywhere. But z_bottom is z_backyard, and the value of z_backyard to use is its future value, after leveling. h_step—we'll limit the values for this one between 6 and 7.5 inches.
And, to some extent, since setting z_bottom affects the rise-over-run of the whole set of steps, z_bottom also affects d_step, the depth (or amount of run) of each step—and we'll also assume d_step to be equal for all steps. But this can be somewhat mitigated by changing the length of the top and bottom landing. (w_step, the width of the path, was fixed at 60 inches through what we might call stakeholder feedback.)
A diagram would be helpful, no?
I've also gathered measurements (good ol' stick, string, and bubble level) for the project. The measurements break down into two groups: (1) the ground leading from the garage door to the edge of the deck (a single arc); and (2) the back yard measured in 2-ft increments 32 feet south of each deck pier (so, basically, six arcs of data). Call it data_1 and data_2 for reference.
data_1 is easy because it is just measured from the deck (the top edge of the deck planks) down to the ground with a (large) ruler. It assumes that the deck level is fixed because otherwise why bother. It also assumes that the east-west slope here is zero, which is not accurate, but not far off—since this bit is not part of the yard leveling scheme, it doesn't need to be accurate, I'm not accounting for the volume of dirt to move.
data_2 was massively annoying to capture. I attached the string a clamp on the wood supports one inch above each of the concrete piers to provide a reference height for each series of measurements. But each pier has a different absolute height—so, essentially, there is a z_string for each series of measurements that defines the height of the fixed string above the ground to give the raw measurements.
This all needs to be adjusted so that the height measurements are taken from the same level—deck level.
There is one more transformation that I did, that might be overkill—but what the hell. As mentioned at the start: if it's worth doing, it's worth overdoing. The distance measured south of the deck is really the distance along the ground, not the distance measured along the north-south axis—so a little trigonometry needs to be done to pull out the y-axis (north-south axis) component.
Then add in the distance between the piers for x-axis (east-west axis):
Then, at this point, I've got the transformed (x,y,z) field data for leveling the backyard.
My memories of July 4th—that's American Independence Day, don't you forget it—split into two categories.
The first, the old ones:
Sitting in the field near... (I have to go to the map to look this one up...) 4th Street and Birch Street in Canton, watching the fireworks. The Fireworks—a Tradition. The Fourth of July Fireworks were something you could count on—a stable point in the year that you knew would be there.
The later, but still old ones:
Driving across Illinois, from Champaign to Dawson or Mechanicsburg, leaving campus to go party with old (as in former, at the time, but now I guess we're getting closer to old as in Old) Scout Camp friends. I'll tell you what life is like growing up in the Flatlands: if you drive down the highway at the right time on July 4th, you can see the fireworks go up in a half dozen towns—no topographical aberrations in the way. Farmer City. Monticello. Decatur. Illiopolis. I don't even know, honestly—the specifics are lost to time and, more honestly, the July 4th party on the other side of the drive. But I'll tell you: there is nothing lonelier that that drive across the glaciated flatlands, seeing the pop-pop-pop fireworks of some small city, imagining a former you there watching, but you're a current you driving, driving driving driving, moving on somewhere else, experiencing your past selves while you transport your current self Onward.
Whither goest thou, America, in thy shiny car at night?
—Jack Kerouac, On The Road (1957)
Oh, hell. If we're going to break out On the Road and talk about fireworks, let's at least break this one out:
The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes ‘Awww!'
That's alright, that's alright—I can sleep calmly now after that, I think.
I've seen so many fireworks from the road. (Presley's what I go by / Why don't you change the stations / Let's count the grain elevators as they go by in the rearview mirror.) A pop-pop here and a pop-pop there. I can hear the fireworks in the distance here in Ballwin, a pop-pop here and a pop-boom there. Blow it up—blow it all up. Fine. Scare 2020 all the way back into its hole and let's start afresh.
The fireworks in Canton, sitting in lawn chairs with my parents, are the ones I miss.
This is from 2012. I've never read it before, but I picked it up as a reference in the Integrating PM and SE book that I'm reading: Andrew Chaikin, Is SpaceX Changing the Rocket Equation?, Air and Space Magazine (January 2012).
You read something like that and—you get a little jealous. The article itself, eight years later, is almost quaint. Falcon 9 works. Dragon just dropped off passengers at the International Space Station for the first time. The notes about rocket engine redundancy are now, hundreds of rocket engines later, obvious. Same thing with fasteners and stage diameters—it's so obvious that you should reduce the number of things that you (a) need to design or build and (b) that you need to design interfaces for and (c) have to learn how to use. Painfully obvious. I don't know about the economics of rocket stage reuse (I would be happy to believe—send references this way, etc.) but the economics of multi-application of components and equipment is just so obvious. And building things in-house? Yessir—obvious. In retrospect. For the rest of us.
How many things exist in your day-to-day life and your day-to-day work that are besotted with obvious things that should be abandoned or changed. There's nothing that is that needs to always be. Everything is contingent. Everyone is winging it. Even the best things were designed by people who did the best the could with the resources they had with the time that was available—nothing is optimal.
I remember having an interview with SpaceX sometime around the time of this article—something for a range safety job, I think, which would have been related to my very first gig at Orbital working on Kinetic Energy Interceptor, which means I was still listing... I have to look this up because I don't remember... AFSPCMAN 91-710 on my resume. I only remember talking to the recruiter because I had to step out of Brookline Booksmith into the freezingass cold of Massachusetts winter to answer classic interview questions such as "what was your GPA?", which I answered grumpily because it's a stupid question when you've been out of school for a few years, but also I didn't have a job at the time so maybe I should have just played the game. I don't know. Years later I had another interview where I was asked by the interviewer to explain why I was a rock star, which I also pointed out was a stupid question. It is a stupid question—hey, sorry, I played the bass guitar, you might confuse us for wallpaper—but, again, what happens if you play the game?
SpaceX didn't change the rocket equation. Delta-V is Delta-V—yesterday, today, tomorrow. Exit velocity, initial mass, final mass.
The physics is simple.
Here we are.
Articles like this one are an envypill for me—eat it up.
We invited Elon Musk to come to the University of Illinois for SpaceVision2005. He flew to Champaign, gave the talk, flew back out—bing bang boom. I didn't see the presentation. I fired all our conference staff for that hour and sent them into the talk, then watched the tables outside myself. I've got to bug people who went there, see if they remember, 15 years ago, what it was all about—see if any of their trajectories were altered by the event.
I've had this one on my reading list since sitting in on a meeting of the INCOSE PM-SE Integration Working Group at a conference last year. (PM = program management, SE = systems engineering.) The topic is right there on a bridge that I'd like to build... or cross... depending on the day. But now I've bumped it up to the top of my reading list while working with the local PMI chapter to do a joint PM/SE online meeting in September. What topics to cover? I don't quite know yet—so let's start with the topics in the book, fan out on the references, and go from there. I'm thinking about how to get one SE and one PM and have them go at topics from their side of the fence, giving a little bit of perspective for the other side to consider. Stakeholder management will certainly be one. Certification might be another. Or not—or more. There's time yet to figure it out.
No one wants to admit it, because there's professional pride involved, but these two disciplines ("disciplines") are mostly the same thing, but with one side focusing a little more on time and the other side focusing a little more on technical content. At a big organization, they are separated to suit the hierarchy of the organization—nerds go this way, suits go that way. Go to a smaller organization and you'll see what it's really about—time and money and technical content are managed by the people who are available to manage them. Oh you're a program manager? That's great. Hold this screwdriver. Oh you're a systems engineer? That's great. Why is this equipment late and expensive? There's no magic in the title—your product is either in the box or not in the box when it's time to ship. If you need something to make you feel good about your role, get a dog.