A system that fails silently is worse than one that fails often. If something breaks and tells you exactly what broke, you fix it in minutes. If it breaks and gives you nothing — no log, no code, no hint — you’re now debugging the absence of information, which takes hours and teaches you nothing for next time.
Most bad tools aren’t bad because they fail. Everything fails eventually. They’re bad because they fail without explaining themselves. The error message “something went wrong” is an admission that nobody on the team thought failure was worth designing for. That’s the tell. Good engineering isn’t the absence of bugs — it’s the presence of a clear path back from them.
This shows up everywhere, not just in software. A process that breaks down and leaves you guessing where — a form that gets rejected without saying why, a shipment that’s late with no tracking update — these are all the same failure of design. Someone decided the unhappy path wasn’t worth building.
Scott Andrew Alpaugh has spent enough time around industrial and technical systems to know the pattern repeats: the teams who write good error messages are usually the teams who write good documentation, who name their variables clearly, who leave the codebase — or the warehouse, or the workflow — better than they found it. Clarity under failure is a proxy for clarity everywhere else. If you want to know how well something is built, don’t watch it work. Watch it break.