Japanese Quality Principles applied to Software

Couple of days back, I was explaining a developer the 5-Whys technique to dig into the root cause of any problem. Basically, you ask the question “why” five times to any problem. In this case, the developer was building complicated web-hooks to a third party platform to overcome an error in syncing. After asking whys enough times, we realized that all that was needed was better exception handling in the syncing code.

This process, called “root cause analysis” was a popular tool used by Japanese automobile manufactures, who revolutionized manufacturing in the 80s.

The Japanese Quality Revolution

For those who are not familiar, the Japanese automobile manufacturers, led by Toyota were responsible for a quality revolution that made cars cheaper and of better quality. The goal was to remove waste at all levels and was popularly known as lean manufacturing.

American car manufactures at that point were not lean. If they had to make 1000 cars, they would make batches of 1000 engines, 1000 hoods, 1000 doors of each kind and so on, and then assemble all the 1000 cars together. The Japanese on the other hand had invented single-piece-flow. This meant, they made one of each part and then immediately assembled it. They also made a whole lot of changes to their factory layouts to enable such a process.

This is better because, say in the American way, you find that the doors you made had a wrong dimension, now you are stuck with 1000 doors that are wrong. That either meant costly rework or even scrapping the entire lot. The Japanese on the other hand, assembled the door within minutes of when it was made, so if the door was wrong, they could immediately stop making any more doors.

Let’s look at a few of these principles and how they translate to good software development

Single-Piece-Flow

In software development, single piece flow should translate to, ship fast, ship often. A large feature should be built in small blocks and should always be integrated in the product. This will make sure that if there any parts that are not compatible with other parts, then this would be immediately known. Also by continuous integration and deployment, you will immediately learn if there are any scale issues.

Small improvements (Kaizen)

The Japanese believed that the manufacturing workers should work with not only their hands, but also their brains. Hence they encouraged the workers to make small improvements to their processes. In the traditional system, workers were not encouraged to think and decisions were made by engineers. This meant that Japanese workers were continuously making small changes to their work that improved the quality.

In software this means that everyone should be encouraged to not only work on their projects, but also look for opportunities to improve the overall workflow and refactor code whenever they get a change.

Visual Management (Andon)

Japanese believed that everything in manufacturing had to be “visual”, so that mistakes could be identified immediately. They divided their inventory in small boxes which were color coded. Each workstation had a red light that could be seen from anywhere in the factory. If the workstation had a break-down or was down due to a quality issue, this red light would come on and everyone in the factory would become aware of the problem.

This is so much true in software. I think each feature in an software application should have a visual user interface. We spend so much time debugging issues which we cannot identify because we cannot see a “red light” on a particular function.

I don’t think we do this often enough. Features are often built by command-line geeks, who do not realize the value of making things visual for everyone to see.

Automation (Jidoka)

Automating repetitive tasks is at the heart of good software development and does not require much discussion. Repetitive tasks are boring and prone to mistakes.

Foolproofing (Poka-yoke)

Developers should be taught to think about what will break their code. Imagining what will break the code, faulty input, load, timeouts will help make for more robust components that will lead to better quality

Conclusion

What is common in software and manufacturing is that a team of people is engaged to build something for a complex for customer.

The heart of the lean system to me, is the way the Japanese manage demand. The Japanese manufacturers, in order to be lean, did not immediately respond to customer demand, because their layouts were designed to build a particular mix of cars. Instead, they chose to use discounts and other techniques to mange demand so that it matched their capability.

In software we often talk of “hyper-growth”. Maybe a time to pause and think on how we can reduce wastefulness. By aiming for more manageable growth we can emulate some of these principles and build software that is cheaper and better.