What Woodworking Teaches You About Software
Craft disciplines have been solving design problems for centuries. Software product teams could stand to pay attention.
There’s a conversation that happens in woodworking called “reading the grain.” Before you make a cut, you look at how the wood grew — the direction of the fibers, where the knots are, which way the tension runs. Make a cut with the grain and it’s clean. Make it against the grain and it tears. Same tool, same motion, completely different outcome depending on whether you understood the material.
Software has a version of this that product teams rarely name explicitly. Users arrive with existing mental models, habitual workflows, latent expectations. A feature that aligns with how someone already thinks through a problem feels obvious. A feature that cuts against it creates friction no amount of good UI can smooth over.
Reading the grain is the difference between a product that clicks and one that requires a manual.
Constraints as a Design Tool
Woodworking is defined by constraints. The wood has a grain, a hardness, a moisture content. The joinery has to account for seasonal movement. The dimensions are bounded by the material you bought and the machine you own. These aren’t obstacles — they’re the thing that gives the work its character.
Product design in software often treats constraints as temporary problems to engineer away. More compute, more features, more flexibility. The goal is to make the constraint disappear.
The better lesson from craft is that constraints define good work. When you can’t build everything, you build the right thing. The decisions that get made under real material and time constraints tend to be cleaner than the ones made when everything is theoretically possible. A cut list optimized for a single 4x8 sheet teaches you more about what matters in a design than an unlimited material budget ever could.
Fit and Finish Are Not the Same Thing
In furniture making, “fit” refers to how parts come together — the tolerance between a tenon and a mortise, whether a drawer slides true, how a door sits in its frame. “Finish” is the surface treatment — the stain, the topcoat, the final appearance.
Bad software conflates these. Teams invest heavily in visual polish — animations, type scales, color systems — while the underlying fit is poor. The features don’t connect logically. The data model doesn’t match how users think about their work. The transitions are beautiful but the architecture is wrong.
Fit comes first. A drawer that slides true with a rough finish is better furniture than a beautiful drawer that sticks. The equivalent in software is a workflow that actually maps to what a user is trying to accomplish, even if the visual design needs more work.
The Prototype Is Honest
Woodworkers build mockups from cheap material before committing to the good stuff. A full-scale prototype in plywood tells you things a drawing can’t — whether the proportions feel right, whether the piece works spatially in the room it’s meant for, whether your assumptions about how it would be used were correct.
The mockup doesn’t need to be pretty. It needs to be honest.
Software prototyping often goes wrong by being too far in one direction — either too low-fidelity to test real behavior, or too polished to get honest feedback. The goal is the same as the furniture mockup: build something real enough that the person using it forgets they’re evaluating a prototype, and watch what happens.
The Shop Floor Knows Things the Drawing Doesn’t
The most reliable signal in woodworking is the one you get when the piece is finally being used. Drawers get sticky in humid summers. Joinery that looked solid fails under real load. A design that made sense in the drawing turns out to be awkward to actually sit in.
No amount of analysis substitutes for watching the thing in real use. This is true in software too, and it’s easy to forget when the feedback loop between a commit and a deployed feature feels short. The user’s environment — their browser, their workflow, their context — is the shop floor. You don’t fully know what you built until it’s there.
Woodworkers have been figuring this out for centuries. The tools change. The principles don’t.