Tag Archives: Backyard Steps Project

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.

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)

Backyard model

I've been meaning to share this for some time, but the actual work on the wall and steps in the backyard have been occupying that time.

In the backyard, the boss wants (1) steps from the garage back door down to the backyard and (2) a flat backyard. It took a long time to design it (some early steps here, starting with measuring the level of the backyard) because I didn't really know how it was going to work. Somehow the steps needed to be integrated into a wall. Somehow the final level of the yard needed to be sorted out. Etc. So I had to teach myself how to use SketchUp, a solid modeling program, to figure it out.

Here's what I came up with. I don't know how to efficiently show the dimensions in the model, so:

  • West-east: outsides of outside piers are 30' 1" (9.14m) apart
  • North-south: steps from garage to end are 36' 4" (11.07m) long
  • Up-down: top of top step to top of bottom step is 7' (2.13m) high (and then each block is 6" tall with 6" of limestone base underneath it, so it's a great deal of Fun if you love Shoveling)
The yard itself, showing the west-east (left-right) slope and the north-south (top-bottom) slope, as well as the deck piers, garage door (upper left) and basement door (lower right).
Adding the wall and step models to the original terrain.
Replacing the original terrain with a flat yard. The wall area under the right side of the deck is a notional design for a shed—not going to look exactly like that, but it's a future project anyway, so we'll deal with it in the future.
Here is, more or less, what has been installed as of... now, except for the curve at the top right. The notch near the upper left corner is a pass-through for the underground electrical cable. I was planning to make this wall one more block deep, but the cable sort of set the max depth.
Comparing the model to a recent pic.
Comparing the model to a recent pic.

Which was harder? Modeling? Or building? Ambiguous. Eventually, while digging, you'll find bedrock and need to stop, but modeling can go on forever. (At least, that was the criticism I was getting.) However, moving blocks in a model was so much easier than in real life, although I appreciated the one week of Popeye forearms after moving 600 of those bastards, plus rocks, etc.

This all divides itself into four phases:

  1. Build the deck wall
  2. Build the steps (this is the boss's most important feature, but it has to sit on the wall)
  3. Build the wall around to the garage
  4. Build the under-deck shed
  5. And then later some of those other blocks sitting around in the yard will be used to build a retaining wall on the northeast corner of the house, but we'll burn that bridge when we get to it.

If any of you want to learn how to use SketchUp, hit me up. I haven't done any solid modeling of my own since college (Unigraphics, which has been subsumed into some other company and software now), and I used to be able to open and explode (technical term) SolidWorks drawings of our flight control to put diagrams in specs and test reports when I was at Mason. Like most things in life, it's pretty easy to do once you know how to operate it, and then the difficulty is in knowing how to organize things.

Overabstraction of the Backyard Steps Project and Backyard Leveling Project

I'll tell you one of my personal hells:


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

Plot twist.

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?

[TBD: diagram]

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.