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.
