The Japanese have a word for the proper way: honte. Honte means what we might call "best practices"; the correct and proper method of doing something with no hacks and no shortcuts. With TPM, however, we want to go beyond honte, we want to achieve Jukutatsu, mastery. In Korean there is the same idea: gosu is the master, and chobo is the novice. What is the road to software mastery?

Visibility

The first facet of jukutatsu is visibility, the ability to see into the workings of the machine. The first action of TPM is to take the covers off the machines. At Toyota, they removed the covers of the machines and replaced them with plexiglass so they could see what the machine was doing. In software, the master does the same: makes the working of the program visible. Do you ever see the memory of your computer? No. It is chobo. Do you ever see the memory space of your virtual machine? No. It is chobo. Do you ever see the memory of your own process. No. It is chobo. Do you ever see the PEB or even know what it is? No. It is chobo. To be gosu, you must see into the workings of the machine. Most programmers act by effect, not by knowledge. They expect if they write X, then dot Y will appear on the screen with no knowledge of how that dot is made to appear. When the dot fails to appear, they are at a loss.

Expert unix programmers know that they can see their process memory space by using /proc/pid/maps and /proc/pid/mem, but how many of them have actually done this and written scopes for proc maps and proc mem? Not many. The main reason I switched to Java from VB eighteen years ago was visibility. I could see Java's source code, but Visual Basic (now .NET) was secret and proprietary. It had a better design than Java, but was more buggy, and when those bugs bit me, there was little I could do. I think the main reason Java is less buggy than .NET is because they publish their source code; it's all about visibility. But reading source code is just baby steps. If you want jukutatsu, you need to see into the machine itself, not just a VM.

Mapping

The second facet of jukutatsu is mapping, expressing the knowledge garnered from visibility. Under TPM, the operators would document their machine, drawing schematics of its operation and actions, constructing timing tables, and flow charts. A map does not show everything; it only shows what the geographer considers important for the task at hand. The machine operator or programmer should do the same: map out the action of system, both what they have created and that which they depend upon in the underlying machine architecture. It is gosu. Only when you can draw what exists do you understand it.

Instrumentation

The third fact of jukutatsu is instrumentation. It is not enough to map the bones of a mechanism, because when it fails, the cause is more likely than not something external. In TPM, the operators learned to design and install sensors that would trigger when abnormal operation, such as vibration, began to occur. In TPM a goal is to detect and forestall anomalies. In software development, the analog is to test inputs, outputs, and the environment. Is memory allocation normal? Are file writes the expected size? In my article Taking Exception to Exceptions I analyze the world of error handling. Instrumentation is not just error handling, but sensing that everything is right.

Decrufting

The fourth facet of jukutatsu is decrufting. In TPM, the operators learned that the cause of failure was dirt, so they react by proactively cleaning the machine. In software development, there is no dirt, but there is cruft. The worst form of cruft is unfreed memory, the bane of every system. Then there are twins, the dangling pointer and the stale handle. Cleaning those up is easy compared to finding latent race conditions. Another source of problems is unwarranted assumptions about the form of input. The list of denizens in the crufty closet goes on and on. The true problem is that most of the cruft is not in your program, but in the programs you depend on, cleverly renamed "drivers" so as not appear like programs. It is not a program, it is a driver, therefore we can ignore it, right? Chobo.

Toyota is still the most profitable car company in the world and the reason is still the same: TPM. Those who practice it are on the path to mastery.