Halloween Candy Machine | Part 6 of 8
Modular components and agile iterations
A coding workflow demonstrated by a woodworking project
This is a standalone article within a multi-part series.
Writing code is a less significant part of software engineering than most people seem to think. The code is, contrary to popular belief, often the easy part. The hard part is the organizational divide-and-conquer process of splitting a monolithic project into manageable components.
Right this moment, the main things 6-year old Nora is learning from her Kiwi Crates are reading, inventorying materials in an orderly way, and orienting her physical materials in the same directions as the diagrams. These are important engineering skills, even if we don’t think of them as engineering skills because they don’t involve math.
Making sense of an initial organization jumble is an adult skill that takes time and dedicated practice to learn. The Kiwi Crate simplifies things, of course, by providing a clearly labeled component list and instructions. Following step-by-step instructions isn’t exactly engineering, but being able to zoom in for the sake of making progress and zoom out for the sake of troubleshooting is.
There’s an unspoken and often poorly-taught art to surveying a jumble of ideas, components, constraints, objectives, and stakeholders, and then serializing the jumble into a step-by-step, linear path towards completion. There’s a slightly different art to periodically unserializing parts of the path back into the jumble when a view of the big picture is required for troubleshooting. It’s not magic, but it’s not a math equation either. It’s an administrative process where sparks of creativity are required to grease the gears when the going gets weird.
My candy machine build took two weeks, with my kids in school and daycare. I’ve been trapped career-wise: my son was five months old when the pandemic hit, my husband is working from home, and I’ve been very hesitant about seeking employment even after the kids’ childcare situations stabilized. So for this particular build, I had plenty of time, but also plenty of interruptions, along with the hard deadline of Halloween itself.
Let’s have a look at how I serialized the jumble of ideas and insights from the candy machine concept into a completed project, and how I addressed the mistakes and obstacles I encountered along the way.
Logistics and Workflow
My personal workflow for woodworking design is an offshoot of my software engineering workflow, which is not dissimilar from my workflows for other creative projects, such as writing and illustrating. This personal workflow is descriptive, not prescriptive. My way is not the only way to organize a jumble into a path, but everyone needs some way. From a STEM standpoint, there are two main takeaways from the breakdown I am about to give below.
The first takeaway is simply that all creative work has an administrative component. I don’t necessarily like it, and I’m not necessarily good at it, but it’s difficult to get creative projects done without it.
The second takeaway is that if the candy machine were a software engineering project, I would not start writing code until the very last stage in the design cycle below (which gets repeated many times over the course of a project). The preceding organizational stages are what make coding easy. Legislators and administrators in charge of STEM education need to understand the importance of explicitly teaching these bigger-picture organizational and troubleshooting skills, rather than simply trying to introduce coding at younger and younger ages.
Here are the stages of my woodworking design cycle.
Pencil and paper sketches. This is a personal preference, but I’ve never found a piece of software that allows for as rapid and uninterrupted a flow of ideas as pencil and paper. I do most of my initial visualization as freeform sketches, without worrying too much about scale. (This is true of user interface design as well as woodworking.)
Taking measurements of external constraints. Once the initial flow of ideas has exhausted itself, I stop and measure the elements of the project that are hard-constrained. For this project, that was the size of the Kit Kats themselves. It turned out to be a lucky accident that a standard 1x2 board is just a bit wider than the short side of a Kit Kat. This greatly simplified my tower design, but it also meant that I had to go back and do another round of drawings.
Creating to-scale orthogonal drawings. I use Adobe Illustrator to create to-scale drawings of my project from side and front views. Everything is rectangular, and I can type in numbers to create precise dimensions rather than dragging out an approximation. At this point, I start making decisions about the dimensions that are inherently arbitrary but usually have a sweet spot in terms of usability and aesthetics. For the candy machine, those decisions were the height of the candy tower, the length of the seesaw, and where to place the seesaw fulcrum.
Writing up a materials list, a components list, and a lumber cutlist. While I’m at the computer, I usually jump back and forth between my Illustrator file and a Google Docs file where I start calculating the amount of lumber I’m going to need for each component. I usually need to make a list of specialty items to purchase as well: in this case a 1/2" dowel for the axel of the seesaw and foot pedal, a 1/4" square dowel for the slider, paint sticks for the tower, and pulleys, D-rings, screw eyes, and tension cord for the pulley apparatus.
Calculating costs. In truth, I find that most projects run over, with unexpected trips to the hardware store and purchases of items that don’t work out (in this case, various types of springs that I never ended up using). My first stab at a cost estimate mainly serves the purpose of deciding whether the project is worth attempting in the first place. I’ve designed more projects than I’ve actually built, as not all of them clear the initial hurdle of “is it worth my time and money?” The candy machine only cleared that hurdle when I realized I could use it as a vehicle to write about STEM and software engineering.
Discovering and de-coupling modular units. This is perhaps the part of the engineering process that requires the most experience to do well. At the beginning of a project, everything looks like it depends on everything else and the whole thing seems impossible to test until every single component is completed. This is usually a recipe for disaster. Instead, it’s important to organize the initial rat’s nest into standalone modules with as few dependencies as possible, in order to build, test, and adapt progressively.
I always choose a starting point for a project by looking for the shortest possible path to a first iteration that can be meaningfully tested. The testing then informs the next round of design for the next component, which circles all they way back to the pencil-and-paper sketches.
Creating session-level to-do lists. My session-level to-do lists are my key to getting anything done. Once I have my master lists in workable condition, I construct to-do lists a work session at a time. The first item on the first list is usually purchasing materials.
Once I’ve done that, I print out the remainder of my to-do list and finally head downstairs to the garage (or start writing code). I have a strong tendency to get paralyzed by overthinking and perfectionism, which means that in order to make any progress downstairs, I need to turn off my upstairs brain and follow the to-do list line item by line item, without thinking too far ahead. Strategically, it’s important to keep the big picture in mind, but tactically, I need to narrow my focus to the current iteration in order to make meaningful forward progress.
A very important caveat, which applies to both woodworking and coding, is that if I am working with unfamiliar tools or materials, this design cycle goes out the window. I go down to the garage and get my hands dirty as soon as possible, and I don’t go back upstairs until I have a better understanding of my tools and materials.
The Woodworking Build Montage
This writeup is intended to be about modularization and agile iterations of testing and troubleshooting, not woodworking per se.
Nonetheless, I’d be remiss if I didn’t provide some sort of build montage, where the boring parts get fast-forwarded into something entertaining. I’ve done my best to include enough visual information in the photos and videos below for experienced woodworkers to reverse-engineer the candy machine build. Woodworking-specific notes and commentary will be restricted to the photo captions.
The seesaw base, tower, and slider could all be assembled independently, but I needed to build all three before I could begin a first round of testing. I quickly realized that the visually impressive 2-foot tower I had in mind for the final product would be very awkward to use for testing, so I decided to start by building a smaller 14" test tower.
After building the separate base, slider, and test tower components, I hit the milestone of being able to test the basic mechanism of the slider pushing the candy out of the tower.
The interaction between the slider and candy tower worked as expected, but I was much more worried about the reset mechanism involving the pulleys and water bottle weight.
The Moment of Truth
There was a subtle physics fallacy in my mind that would turn out to have considerable design implications. I still thought the seesaw mechanism was required to help free the slider from the candy tower. Earlier, I had clamped a few spring clamps to the slider in order to simulate the weight of the water bottle. I then held the the base in my hands and physically tilted it back and forth, eyeballing the angle at which gravity pulled the slider out from under the tower.
According to my notes:
Four pieces of candy took one spring clamp and about a 30 degree angle.An entire 14” tower required two spring clamps and about a 45 degree angle.
It’s easy in hindsight to spot the fallacy: When the weight is attached directly to the slider instead of being pulled by a string through a pulley, tilting the base produces only a small amount of force in the direction we want, parallel to the base. By contrast, when we use the pulley, almost the entire gravitational force of the weight is transferred in a horizontal direction, easily releasing the slider.
But I didn’t yet realize this, so I went ahead and built the seesaw axel brackets and attachments for the pulleys. Though it wasn’t functionally necessary to use a jigsaw to create attractive curved shapes, I made the decision to do the decorative work at this stage because I wouldn’t be able to go back and do it later once everything had been assembled.
After building the base, slider, tower, seesaw components, and pulley attachments, I had finally arrived at the moment of truth. Nora’s very first try worked beautifully. It was picture-perfect.
Then I turned my husband Jeremy loose on the candy machine.
His show of brute strength uncovered some problems. I had not anticipated the candy flinging.
A first step towards addressing the problem was to constrain the range of motion of the seesaw. I did so by temporarily putting a spring clamp in the way, and then let Nora continue testing.
There are a couple things worth noting about the video clip above. First is that the proof of concept was a success. The pulley and slider worked as designed, and held Nora’s rapt attention as she unloaded the entire tower.
Second is that it’s boring to watch the entire video.
Third is that it’s important to keep testing through the tedium. Over the course of the mostly successful testing session, there are two odd hiccups that I later identified as candy jams. There is also the solvable but annoying problem that when the seesaw is tipped far enough to the right, the overhanging portion of the candy tower actually contributes its weight to the right rather than the left side of the seesaw, trapping the seesaw in the candy dispensing “down” position.
One final note: an astute observer might have noted the presence of Hershey’s bars in some of the above photos and videos. Why Hershey’s bars? I don’t know. I sent Jeremy to the store to get Kit Kats, and he came back with Kit Kats and Hershey’s bars. The Hershey’s bars were slightly smaller than the Kit Kats, but I did my best to roll with it. As both a software engineer and a parent, I’m fairly accustomed to mid-project shifts in design specifications.
Toddler Nora: "I want an orange shirt."(Two months later, Mom brings home the perfect orange shirt.)Nora: "Where's the balloons that were supposed to be on it?"
Half-Finished Snowmen, Ready to Ship
Here’s another very common software engineering phenomenon: I was at almost exactly the halfway point of the candy machine project, but I felt done. The candy machine wasn’t yet reliable, but the proof of concept had been put on display.
Jeremy once casually mentioned to me that as a kid, he rarely finished building the snowmen he started. For some reason, this upset me tremendously and I vowed that our kids’ lives would amount to more than a backyard full of half-finished snowmen. It was a sad and silly enough image that it became something of a catchphrase in our household.
I’m not exactly claiming that real-world software products ship at this stage, but the urge to push them out the door prematurely is awfully high when a project is running over budget and behind schedule and the proof of concept has been excitingly demonstrated.
Guilt was also getting to me at this point. Not just the mom guilt of giving my kids excessive screen time so I could work on something intrinsically frivolous, but also perfectionist guilt that I’d made that physics miscalculation during the design phase and directed my energy toward solving the wrong problem.
One week till Halloween. No pressure.
Next in the candy machine series: Taking the proof of concept to the finish line.
