Last month, I spent three weeks in my garage rebuilding a 1972 Honda CB750. Seized engine, rusted chrome, electrical system held together with hope and electrical tape. By most measures, a terrible project.
But as I pulled the engine apart and cleaned decades of carbon buildup from the pistons, something clicked: This is exactly how I should build software.
Start with constraints
The CB750 was designed in 1969 with brutal constraints: reliable, affordable, serviceable with basic tools. No computer diagnostics. No proprietary parts. Everything could be taken apart and put back together by a guy in a garage.
Modern bikes are "better" on every metric—faster, smoother, more efficient. But try servicing a 2024 sportbike without a dealership's diagnostic computer. The complexity becomes the constraint.
The lesson: Design for your actual constraints, not your aspirational ones.
When I build education technology for rural schools, I'm not designing for gigabit fiber and unlimited budgets. I'm designing for intermittent power, limited bandwidth, and teachers who have 47 other things to do.
Just like that CB750: Make it work with what you've got.
Fewer moving parts = more reliability
The CB750 engine has four cylinders, four carburetors, eight valves, and about a dozen major components. That's it. No fuel injection, no computer, no sensors.
When something breaks, you can see it. When something needs adjustment, you can feel it. Simplicity isn't a compromise—it's a feature.
I see the same pattern in software. The most reliable systems I've built are the ones with the fewest dependencies, the clearest logic, the most obvious data flow.
Every component you add is another thing that can fail. Choose wisely.
Maintenance is design
Honda engineers knew that oil changes, valve adjustments, and carburetor cleaning were inevitable. So they made them easy. Drain plug at the lowest point. Valve covers that come off with four bolts. Carburetors that disconnect with two screws.
Maintenance wasn't an afterthought—it was core to the design.
How many software projects treat maintenance this way? We call it "legacy code" and complain about technical debt. But really, we just didn't design for change.
The lesson: Assume things will need updating, fixing, adapting. Design for that from day one.
When I build ProScola lesson plans, I build them knowing teachers will adapt them. The system expects modification. That's not a bug—it's the entire point.
The rhythm of deep work
Rebuilding a motorcycle is meditative work. You can't rush it. Each step has to be done right or the whole system fails.
Torque the head bolts in the wrong sequence? Warped head. Skip cleaning the carburetor jets? Runs rough. Forget to gap the spark plugs? Won't start.
But when you slow down and focus on one thing at a time, there's a rhythm. Disassemble. Clean. Inspect. Replace what's worn. Reassemble. Test. Adjust.
It's the same rhythm I use for systems design:
- Understand the current state (disassemble)
- Remove what doesn't work (clean)
- Identify the real problems (inspect)
- Fix the root causes (replace)
- Put it back together better (reassemble)
- See if it actually works (test)
- Refine based on reality (adjust)
You can't skip steps. You can't fake your way through. The system will tell you when you're wrong.
Know when to walk away
Three weeks into the rebuild, I found a crack in the engine case. Small, but structural. The kind of thing that would eventually leak oil and ruin everything else.
I had two choices: weld it (risky, time-consuming, might fail) or find a new case (expensive, delays project, guaranteed to work).
I found a new case.
In software, we call this "technical debt." In motorcycles, we call it "cutting your losses."
Sometimes the right move is to throw out the broken part and start fresh.
Not because you failed. Because you're building something that needs to last.
The joy of making it work
After three weeks of work, I turned the key, thumbed the starter, and heard that beautiful inline-four purr to life. No misfires. No smoke. No leaks. Just smooth power and mechanical perfection.
That feeling—of taking something broken and making it work again through patience and craft—is why I do this work.
Whether it's a motorcycle engine or an education system, the principles are the same:
- Design for your real constraints
- Keep it simple
- Make it maintainable
- Work with rhythm and patience
- Know when to cut losses
- Take pride in making things work
That CB750 is now my daily rider. Reliable, beautiful, and built to last another 50 years.
That's the kind of system I want to build. Whether it runs on gasoline or code.
Building systems that need to last? Let's talk about design principles that actually work. Get in touch.