What a 1920s Loom Taught Us About Software

Before there was a Toyota, there was a loom.

Sakichi Toyoda was an inventor in a country that was still mostly weaving cloth by hand. His obsession was not cars. It was the automatic loom, and the problem he kept returning to was simple to state and hard to solve: when a single thread snapped, the machine kept weaving. It produced meters of flawed cloth that no one could sell, and a person had to stand and watch every machine to catch the moment it went wrong.

His answer, in 1924, was a loom that stopped itself the instant a thread broke. The defect could not propagate. One person could now oversee dozens of machines instead of one, because the machines only asked for attention when something was actually wrong. The Japanese word for this idea is jidoka, sometimes translated as “automation with a human touch.” A machine that knows when to stop is worth more than a faster machine that does not.

That single principle, a defect should stop the line at the source, is the seed the entire Toyota Production System grew from. The patent royalties from the loom helped fund the car company his son started. And the way of thinking outlasted both. It is the same way of thinking we reach for when we build software, almost a century later, in a completely different medium.

Ask why until it is the root

Toyoda is also credited with the habit that became the five whys, in Japanese naze-naze bunseki. The rule is almost embarrassingly plain: when something goes wrong, ask why. Then ask why about the answer. Keep going, usually about five times, until the answer stops being a symptom and starts being a cause you can actually remove.

A machine stopped. Why? A fuse blew. Why? The pump was overloaded. Why? The bearing was not lubricated. Why? The lubrication pump was not pulling enough. Why? Its intake was clogged with metal shavings. Replace the fuse and you are back tomorrow. Fit a filter on the intake and the problem is gone.

Software has the same trap. A page returns an error. The fast fix is to catch the exception and move on. The five whys point somewhere else. Why did it error? A value was null. Why was it null? A field was optional that the rest of the system assumed was required. Why did the system assume that? The type allowed it and nothing enforced the contract. The real fix is not a try-catch. It is a type, or a constraint, that makes the bad state impossible to reach. One closes the ticket. The other closes the class of ticket.

This is why we write down the cause, not just the patch. A bug fixed without understanding why it happened is a bug you have agreed to meet again.

Go and see

The third idea is the one most often skipped, and it has a name too: genba, written 現場, “the actual place.” The principle is that you do not understand a problem from a conference room or a status report. You go to where the work happens, where the value is created and where the failure occurred, and you look with your own eyes.

On a factory floor that means standing at the machine. In software it means going to the real thing instead of the description of it. Read the actual logs, not the summary in the ticket. Watch a real user move through the flow, not a wireframe of it. Reproduce the failure on the system that failed, with the data that triggered it. Most wrong fixes come from solving the problem as it was reported rather than the problem as it is. The report is a map. Gemba is the territory.

Going to see is slower at the start and far faster across the life of a system, because you fix the thing that is actually broken on the first attempt instead of the third.

Improve a little, forever

The last piece is the one people quote and rarely practice: kaizen, 改善, continuous improvement. Not a rewrite when things get bad enough to justify one, but small, steady refinement that compounds. The loom did not arrive finished. It got a little better with each version, each defect understood, each cause removed, until the result looked inevitable.

A codebase is the same. We leave it slightly better than we found it on every change, so quality rises over the life of the product instead of decaying toward the next rewrite. Maintenance is not a phase that comes after the work. It is the work.

Why this is in our questions, not just our history

None of this is decoration. It is the reason our homepage is built around a set of questions rather than a list of features.

The lens behind those questions is older than software. It is called 5W1H, the practice of interrogating a problem from every side, what, why, where, when, who, and how, before deciding what to do about it. It is the same discipline Toyoda’s heirs used to take apart a stalled machine, applied to the decision of what to build and how to build it. We ask what a product actually needs before we add to it. We ask why a feature exists before we keep maintaining it. We go and see how the current system really behaves before we change it.

A loom that stops itself. A question asked five times. A walk to the actual place. A small improvement, repeated. These are not Japanese curiosities we pinned to the wall for flavor. They are a hundred years of evidence that the careful way is the cheaper way, and that software, like cloth, is best made by people who refuse to keep weaving once a thread has broken.