Since announcing EListMan in my prior post, Please unsubscribe if unexpected, I’ve taken some time off from it to pursue my other passion. This includes indulging in some technical projects adjacent to it, namely preparing to build the StewMac Ghost Drive pedal kit I bought months ago.
Still, no matter where I go, or what I do, I see the Quality Mindset everywhere, and I couldn’t resist sharing this.
As I was surfing around doing some “research” before getting started, I found the following video—and started laughing out loud a couple of minutes in:
Click to watch the YouTube video from the DIY Guitar Pedals channel, “New Pedal
Builders - The Most Common Mistake.”
Note that by “PCB” he’s talking about the printed circuit board containing the “business logic,” if you will, of the actual effect. The rest of the enclosure is essentially just I/O: the input and output jacks, the on/off switch, and the power supply jack. He argues that once the PCB is wired up inside the enclosure, troubleshooting and repairing problems becomes much more time consuming and complex. And, of course, with a well tested PCB, most subsequent issues are problems with the enclosure (“offboard”) wiring, not with the PCB.
Sound familiar?
This guy, talking about wiring up effects pedals, ended up making a strong case for a Test Pyramid based testing strategy without even knowing it. I don’t know that I’ve explained this concept any better in my decades of trying to communicate it to programmers.
One may split hairs to say that, well, testing a fully wired PCB is more of a medium test than a small test. Well, he didn’t mention probing individual components and portions of the circuit with a multimeter, but I bet he does that, too. That would cover small tests for sure.
Even so, the important point isn’t to argue over the exact classification of any given test. The Test Pyramid language is a tool to help us navigate and collaborate—there’s value in the map even if it only approximates the terrain. The important point is to realize the importance of designing, building, and testing systems one component or layer at a time. Waiting until everything’s built to test like a user would is a recipe for failure and pain—or in other words, complexity, risk, waste, and suffering. Systems thinking is systems thinking, and it requires the same disciplined mindset towards development and testing no matter the medium or the product.
Maybe more programmers should try to build a few guitar pedals—perhaps the wax on, wax off approach will transmit more wisdom than I ever could.