Monday, May 17, 2004

Notes on Toyota

by Asim Jalis

INTRODUCTION Here are my notes on the Toyota Production System and how it relates to software. These are based on the operations class by Alan Leong (University of Washington MBA program). TOYOTA PRODUCTION SYSTEM We've been reading about the Toyota Production System in the operations class. It is made up of a lot of disconnected pieces which work together and reinforce each other. Toyota invented the concept of lean and just-in-time manufacturing. But companies that use these ideas in isolation fall flat on their faces. It's like adopting refactoring without adopting unit testing. In some ways TPS is like a giant puzzle that I am gradually unravelling. I would love to visit a Toyota plant sometime and watch it in action. TOYOTA'S SECOND PARADOX Durward Sobek calls Toyota's design process (Set Based Concurrent Engineering or SBCE) Toyota's "second paradox" which gets less attention in the press than Toyota's lean manufacturing process. Mary Poppendieck references some SBCE literature but does not seem to dwell on it in her book. The main idea is that instead of fixing a design and then iteratively improving it Toyota engineers start with a set of designs. They don't artificially choose one over the others. They maintain the whole set for as long as possible delaying the weed out process. This reduces the number of design decisions that need to be made. There is no decision. It's all exploration for a long time. No more tense meetings. Since there are no decisions to be made there are fewer reasons to meet. Designs which are clearly flawed or unimplementable are eliminated without much discussion. There is actually an elegant process for doing this wihch I will describe later. There is something profound going on here but I can't quite put my finger on it. There is the same flavor in XP's insistence on keeping stories deliberately vague. But while there is a common flavor here these are not the same thing. ENGINEERING NOTEBOOKS Here is how the Toyota engineers narrow their design choices. The narrowing is quite systematic. They want to remove arbitrariness from it. So every narrowing is based on some general principle that has wide applicability. These principles are recorded in engineering notebooks. This way on future projects the same narrowing can occur earlier. To narrow you have to cite a well-accepted principle from a notebook. The only room for innovation is to invent a new previously unknown principle. The notebooks basically use legal precedence to evolve in the same way that the law does in the US. ROMAN LAW VERSUS COMMON LAW The principles in the notebooks are of this form: The steel rod cannot be bend beyond X degrees. I.e. the principles are constraints. They reject rather than accept. They are not really a catalog of good practices or patterns. But rather catalogs of anti-patterns. There is a subtle difference. Patterns restrict your freedom to design. Anti-patterns do not. It's the old Roman Law versus Common Law debate. In Roman Law everything is forbidden unless it is explicitly allowed. In Common Law everything is allowed unless it is explicitly forbidden. Toyota's engineering books use Common Law rather than Roman Law. Everything that is not prohibited is allowed. The patterns community sometimes falls into the trap of using Roman Law: everything that is not allowed is prohibited. MORE DETAILS ON SBCE Here is the part that is difficult to believe. They simply refuse to make decisions until they have to. They keep all the alternatives alive for much longer than would seem rational. (This is a little mind boggling. But this is precisely how Toyota does it according to Durward Sobek. Sobek's initial work elicited shock in the US academia so he forced himself to learn Japanese and spent 6 months in Japan to confirm his initial findings.) Each alternative design is taken all the way to prototype phase. At this point the concrete prototypes are evaluated and a decision is made. CRITICISM OF HILL-CLIMBING The main criticism the Toyota and Nippondenso engineers offer of incremental hill-climbing is that it does not lead to breakthroughs -- only to small improvements. The set-based approach they claim leads to designs that can be years ahead of the rest of the market. Nippondenso is a Toyota supplier that uses set-based concurrent engineering even more religiously than Toyota. Here is something else that is weird and which is completely counterintuitive. Toyota's design process takes less time than all of their Japanese and American competitors -- even after American companies have started shortening their design cycles. Toyota takes 27 months versus about 36 months for most of its US competitors. The Japanese companies tend to do better than US companies, but still lag behind Toyota. The man-months figures for Toyota are even better since they use smaller teams than their competitors. Intuitively, this sounds like nonsense. How can taking multiple designs to prototype stage be faster than building just one design? SBCE AND SOFTWARE So how can SBCE be applied to software? The simple application seems to be to develop multiple designs at the same time. This could lead to a mess. Also this seems like a recipe for a combinatorial explosion. It might be useful to keep alive a representative of each broad family of designs and kill the others. This has a darwinian flavor. But it's hard to believe that this can work. Just the way our brains are wired we assume we know everything. So it seems to us (possibly incorrectly) that it should be possible to kill off the unfit design solutions early on and save money and time by investing only in the "best" solution. What if even after hearing all the pros and cons the best decision is not really the best one. In software keeping all these alternatives alive could lead to a logistical nightmare. But maybe not. HOW FAR CAN YOU TAKE THIS How far could you take this approach? Could Toyota defer the decision of what it was making? One prototype could be a car, another a lawn mower? There is a delicate tension between expand and contract. The traditional brainstorming approach is expand-contract-hold. Toyota's approach is expand-hold-hold-hold-contract. The other parameter is how far you are willing to expand. How wide can you spread the net without getting dizzy. APPLICATION TO MATH I noticed this in math. That I would reject an approach too early and then someone else would carry that much further and find a very elegant solution to a hard problem. XP forces hill-climbing and the pre-XP design phase is too short to consider multiple design solutions. POSSIBLE WAYS TO APPLY THIS TO SOFTWARE Approach #1. Spend some time perhaps a month coming up with feasible designs for solving a software problem. Narrow the set down to 5. Implement all 5 each iteration and after a few months narrow this down to 3 and then to 1. Approach #2. Adopt the following principle: Do not make decisions unless they are obvious. Defer all other decisions until they become obvious. Don't worry about the combinatorial explosion. It might never happen. Narrow the solution space using these narrowing concepts: (a) Your capabilities: Whatever you cannot implement can be rejected. (b) Market research: If you cannot define a market for it, or based on preliminary market research there is no potential market for the product, you can reject it. For user interface decisions and for other design issues, if you have no obvious way of making decisions, then don't. Allow the same program to display in different modes using compile time configuration parameters. E.g. use #define to turn features ON and OFF. I still want to see this fleshed out into a real program. It's hard to believe that this could work, especially for an individual or a pair or a small team.