Design for interruptibility

Trailhead:Design for assembly

"Focus and finish" is a nice adage for projects. Do one thing—and focus on that one thing until it's done. I've never seen it actually happen like that in the wild, but it seems like a theoretically sound idea for getting things done right and done quickly.

At home that theory shatters into pieces. For any large enough project I have to deal with the effects of fitting that project into the times when it will fit between work, school, and other around-the-house activities, and if the project is being built outside it has to fit during the daytime and around the weather.

In reality, "focus and finish" is more like "prepare to get interrupted".

Really I'm thinking about this project with the steps and wall in the backyard. I started working on it in November during a long stretch of warm, dry weather. Fairly early on in the project—after I dug the trench, but before I finished laying in the base rock—the weather forecast called for rain. OK, no problem. The finished project has to live outside in the elements, so we'll just let the project under construction live in the elements.

After bailing out that water, I still had to wait for some time for the water in the crushed rock to go away as well because it wouldn't compact correctly while wet. (Side note: with the use of this free water level I could tell where more base rock needed to be added to make the whole thing level.) Also, some of the dirt (clay) washed off the sides of the trench—not enough to cause problems with stability, but it was inconvenient to remove and, if it happened often enough, sure to cause some problems with the trench.

Now I keep an eye on the forecast and plan for the interruptions. It doesn't prevent water from getting in, but it limits the effects and lets me get back to work sooner. It's not just about preventing the water from getting in that one spot, but not starting too much at once so that more work is exposed to problems.

Review in thirds

Trailhead: Stefanie Flaxman. Catch More Writing Mistakes with This Underutilized Proofreading Trick. Copyblogger (2015-07-01). (courtesy of Filament's Monday Morning Meeting, 2021-01-25)

The second suggestion in that article is: proofread backwards. Start at the end, then work back towards the beginning. Her point is that when you see the words you wrote in a different order, it's easier to spot errors. The words look fresh—not like words that you've read a hundred times before.

(Coincidentally, in the background, I just got Rob Walker's The Art of Noticing #62, How To Get a New Perspective, and it mentions "the fog of familiarity".)

But there's one more point I would add to that: it's tiring to read and review things, and over time you run out of energy, focus, attention. At some point, if you haven't quit, you're just trying to scrape by to get to the end, doing a progressively worse job.

In engineering, we have reviews for a variety of documents that we make—requirement reviews, test reviews, flight reviews, etc. A requirement specification for a complex aerospace system can easily run past 100 pages. Few people have the stamina to give page 100 the same time and attention as page 1. I've seen some reviewers just make comments about the cover page of the spec and leave it at that. (Thanks?) I've seen requirements at the end of a spec that referred to the wrong program, meaning that whoever put the spec together themselves didn't make it to the end to clean up the requirements they copy/pasted from another spec, nor did the reviewers who approved the thing before it was sent to us. I understand—reading a spec is murderously boring.

There is an easy solution, and it's one of my best review hacks. When I run a spec review, I recruit volunteers—some will start at the one-thirds mark, and some will start at the two-thirds mark. Then I have some assurance that the middle and end of the spec get some scrutiny.

That's it. It's a really superficial hack. It's not as good as putting in the work to make reviews better, but it helps.

The Captain's Newsletter, 2021-W03

The Captain's Newsletter, 2021-W03 - Take a break

We're back this week to remind you: get busy, but don't get too busy. If you can even do anything about it. We're at that point at the end of January when the fresh and new plans for the New Year often get lost somewhere on a shelf behind some things and forgotten, but still somehow that time for improvement and resolution has been filled by... something. Don't sweat it--there's still time for reflection and redirection, if you want it.

Get busy with us: /captain.

Design for assembly

"Design for assembly" is an idea in engineering design that is meant to prevent you from designing an amazing, beautiful machine that is difficult or impossible to build.

I'm running into that problem occasionally with the wall and steps I'm building in the backyard—probably because I'm not an engineer, I'm a systems engineer, so I've never really had to design anything myself. The wall, as seen from the model, looks simple. (And it is simple, I suppose, but I'm inexperienced.) As I'm building the steps up to the garage into one leg of the wall, I'm finding little puzzles to solve during assembly that I didn't think of before.

The main problem is: a simple retaining wall is built with a layer of ~1-inch rocks behind it to help with drainage, so I cut the dirt so that there was room for that rock on both the deck wall and the wall under the steps. However, the wall under the steps will—obviously—have to support the steps, so it's not a good idea to put that chunky drainage rock there because it will be a poor support for the steps. Now I find myself making some slight adjustments to the design during assembly—filling in that space with the base rock (limestone, with large pieces and fine pieces that can all be compacted into a fairly solid mass).

This should have been obvious from the design, but I only modeled the large things like the retaining wall blocks, not the other bits that go around them such as size and shape of the base rock, or how the dirt would need to be cut away so that things could be built. In my mind assembly was just a simple shovel problem. In reality it's a moderately hard shovel problem, and each layer of steps takes extra time now as I have to imagine what that layer will look like—the dug hole, the base rock, the retaining wall blocks—before starting.

Assembly is an unloved aspect of engineering, and it should get more respect than it does, but it is only noticed when it doesn't work. Perhaps that's because much of assembly work is tacit knowledge—knowledge gained through experience, often unwritten, unspoken, known but unknown. Design is thought of as the Real Work. Assembly just happens. Don't think about it like that. Assembly is dark magic, and if complex parts and subassemblies and assemblies can be put together the way they are supposed to, that's because someone did the job right.


A reasonably good paper that explains DFX, or "design for x", where x = assembly, manufacturing, test, etc.: Kuo, Tsai-C., Samuel H. Huang, and Hong-C. Zhang. "Design for manufacture and design for ‘X’: concepts, applications, and perspectives." Computers & industrial engineering 41.3 (2001): 241-260. (pdf)

Dishes

While washing dishes I remembered a story from Thich Nhat Hanh which is called "Washing Dishes". I thought about it because it wasn't just the dishes I was thinking about, literally and figuratively.

Literally, I was trying to find a podcast episode to listen to while washing, as well as thinking about what to do afterward. Figuratively, I've been doing the same thing in other activities—relegating the thing being done to the smallest corner of consciousness I could fit it into so that I could use the other space to think about something else. Yes, I know it doesn't work, but it happens all the time.

Thich Nhat Hanh's story is about focusing on washing dishes in order to live in the moment—to really live by being conscious of the thing you're doing in that moment. It's good advice, but it's not an aspiration of mine. Only in cases of frustration—of having missed some detail or felt squeezed by the pressure of trying to fit too many things in at once—do I think about it, but by then it's too late, and the moment has passed. As he puts it: "I will be constantly dragged into the future, miss out on life altogether, and never able to live in the present moment."

The other day at work I had my work headset on one ear monitoring a meeting, headphones on the other ear listening to a class, and, for reasons that are unclear to me, occasionally flipping through my phone or opening a browser window. What a waste. It would have been just as useful to lay on the floor and do nothing. At least it would have been relaxing.

Maybe it should be an aspiration, at least a minor one—to try one thing a day and and have that One Thing be the only thing being done, thought about, etc. Maybe I'm not interested enough in doing it as an all day every day practice, but just slowing things done for a moment sounds beneficial.

Alice's adventures in metricsland

I was looking for something else entirely when I ran into this sequence from Alice's Adventures in Wonderland:

“Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where—” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

“—so long as I get somewhere,” Alice added as an explanation.

“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

Since I was thinking about metrics at work around that time, the correlation seemed obvious to me. I think we've all been there if we have to get our work performance measured: the boss wants you measure something, measure anything, just bring a number or, better yet, a chart with the line pointing up and to the right.

Is that the thing you should be measuring? Is that value you're tracking meaningful? Helpful? Is it going to be gamed by your workers because they know that it's (a) neither meaningful nor helpful and (b) they get rewarded if it points up and to the right and punished if it doesn't? Oh, you bet it will. And, in a sense, it should. It's a Catch-22. Only insane people would behave as if an insane system is sane, whereas deviation is a sign of sanity.

A quip from Marilyn Strathern (the de facto version of Goodhart's Law): "When a measure becomes a target, it ceases to be a good measure."


Here's the part I was originally looking for because I think it's also project related:

“But I don’t want to go among mad people,” Alice remarked.

“Oh, you can’t help that,” said the Cat: “we’re all mad here. I’m mad. You’re mad.”

Consume and produce ratios

Taking off from an earlier post, Consume and produce cycles (2020-08-20)...

Here's another riff from Matt Mullenwegg's interview with Shane Parrish on The Knowledge Project that had me thinking. (The earlier one: Make more decisions.)

[49:44, Matt Mullenwegg] I think a lot about that efficiency of time... I think one downside of synchronous communication is it's kind of 1:1, so the time that it's taking to communicate the information is also what it takes to consume it. That's kind of inefficient. On the other end of the spectrum is maybe a book that someone took a lifetime to write, and it can take you a few hours to read. That's a multiple thousands-to-one ratio, so that's really dense and valuable. And then probably the worst is things that take people a short amount of time to create and you a long time to consume.

[51:06, Matt Mullenwegg] This is why we always want really good notes out of meetings. By the way, if every meeting is transparent and has really good notes or a recording, people don't feel the need to be there, and so the meeting can be smaller, which also means it's more effective. Where it's not everyone is like, I'm not in this meeting and I'll have no idea what happened and my voice won't be heard.

There is a general, casual tendency to just sling documents or meeting invitations out into the fray. I'm done—[heave]. Then the people on the other side of that interaction have to catch the thing being heaved and make sense of it. Or, just as likely—they don't, because they don't have to make sense of it, really. If someone throws a bag of crap at you, you're going to dodge it reflexively.

I don't think it's a mean-spirited tendency to do it like that. There's not enough thought put into crafting and writing in technical work. (See also: Good writing would make work so much better.) People can do the hard analytical work, and then it feels like the job is done—smash it all together and ship it. It's efficient (maybe) for the person sending, but when you add up the extra time it takes for each of the receivers to consume it, it's inefficient for the whole system.

Ratios matter. System effects matter. That ratio of consumption-to-production is important. Spending an extra five minutes to write an agenda for a meeting and to make the invitation clear can easily save more than that for the whole team in reading and comprehending the message, in having a useful meeting, etc. The trick is developing the taste to know how and the patience to think from the receiver's perspective.

Wrong way

Let me tell you how this started—it was a typical Wikipedia rabbit hole. I was looking at the page for Broadway (Manhattan) for a previous post (Traces). Then I followed a link to List of ticker-tape parades in New York City. While I was scrolling through that list, I came across this entry:

August 5 – Douglas "Wrong Way" Corrigan following flight from New York City to Ireland (he was scheduled to fly to California).

What? I can't believe I've never heard about this story in aviation.

I don't have any more information than what's available in that page on Wikipedia, so you can go there and get a fuller set of details. The short story is: he built his own plane (he was also a mechanic on Lindbergh's Spirit of St. Louis), he applied repeatedly for a flight clearance to fly from New York to Ireland but was repeatedly rejected, he "mistakenly" flew from New York to Ireland on a flight plan that was supposed to take him to California.

There's a man after my own heart.

Given my line of work, that's a funny thing to say. In systems engineering, a great deal of my job involves making sure the thing that was built matches what the customer wanted, what the requirements spec says, what the test plan says, etc. You really have to work hard to drive out expected and unexpected problems. In that context—making things that the public will fly in, making things that will fly above the public—there's really no tolerance for surprises. As it should be. We have our forums for developing wild new ideas in aerospace, but there's a palpable tension between production (making things the same way every time) and prototyping (making something new once). It's a different approach, and it really takes a different kind of person for each.

But: here's to the troublemakers—some of them, at least. It's a hair's breadth between feats of bravery and feats of stupidity. It's a hair's breadth (in the mind of the beholder) between knowing you can do something and thinking that you know how to do something. Like jazz (or at least like my marginal understanding of jazz), you need to have the talent, know the forms, and put in the work for deviation to become progress. Sometimes it's better to ask for forgiveness than to ask for permission.

His plane was due to be shown at an event in Chino in July 2020, but that got canceled. Just looking at the photo of that plane makes my throat tighten up a little. Over the Atlantic in that lagwagon? Oof.


One more thing—Frank Zappa wanted to have his say about deviation from the norm:

Traces

Trailhead: Richard Campanella. Electric Avenue: New Orleans' own Champs-Elysees was once extraordinary -- and could be again. New Orleans Times-Picayune (2018-06-10). (Courtesy of Rob Walker's The Art of Noticing newsletter, #61: Hunting for Feelings)

Go ahead and read that article and come back. I'll wait right here.

...

OK. A secret pastime of mine is paying attention to places where old bridges, roads, and railroad tracks show their haunted remains in the current scenery. It's almost an obsession to look at satellite images and see where railroad tracks used to be—that diagonal line of trees cutting across otherwise square cornfields, swooping into a small town, the 45-degree diagonal bending at the last moment as it intersects the town and matches up to the street grid.

In real life, there was the gully across the street from where I grew up in St. David where the railroad used to branch off the main line and go to the coal mines.

And there's the place in Lewistown where the railroad branched off the main line and crossed Main Street near the high school, and connected to some other line that must have gone into downtown and on toward Cuba—anyway, wherever the ends went, the middle used to cut across the edge of our yard. And at camp there were the remnants of old County Line Road, between Knox and Fulton Counties, now partially underwater since the dam for Lake Roberts was installed in the 1970s. (Bonus points if you ever found the remnants of the house on the east side, near Horseshoe Bend.) And the hulking grain elevators that you can see, a dozen at a time across the glacier-scraped middle of Illinois, giving away the shape of old rail networks that no longer exist. And there are the old mining roads and trails that I explored in Panamint.

Panamint City, Surprise Canyon Road ("Road")

I could wear you out with examples of old roads and bridge pylons and on and on. But it's not just the remnants themselves, but the remnants of design decisions that sprung up around them. In that New Orleans article, it mentions how the old canal and railroad still exist, not in their original forms (they're long gone), but in the shape of the neighborhoods around them, in the long empty stretch to the river where they used to lie, in the names of places that survive.

Here's another example: Tanner Howard. Native American routes: the ancient trails hidden in Chicago’s grid system. The Guardian (2019-01-17).

And in Manhattan, Broadway, which meanders against the grain of the rest of the island's grid, was once the Wickquasgeck Trail, where it was once a sensible route across swampy land.

Some traces weren't on the land, and their remains are getting smaller and smaller, forever and ever, amen.

So many of the reasons that things were built have since buried or lost or burnt or rebuilt or unbuilt, but their influence remains. I wonder about that from two sides. (1) Do the old roads tell us something that we're missing? We can knock down any hill or fill in any swamp now—we have the tools and we have the talent, etc. It's not quite Chesterton's Fence, since the fences are long gone, just the bend in the road where the fence used to be. (2) What are we—what am I—building today that will shape the layout of the future? Are we being good ancestors? (See also: The Long Now Foundation.)

I don't know if I'm the only one with this habit of finding the traces of old things in the current. It's not like I chose the habit, it chose me. There are people like Sarah Parcak whose literal job is searching for traces of old things from space—so maybe I chose the wrong career path.

The Captain's Newsletter, 2021-W02

The Captain's Newsletter, 2021-W02 - Out of control

This week in the newsletter we explore 1980s children's TV, explore drawing, explore the wilderness, explore shipping version 1.0, explore corn tortillas, explore unstructured time, and explore our technique. Everything is exploration if you look at it hard enough.

Wander with us: /captain.

Many other links don't make the newsletter: notes.kirkkittell.com.