Selectivism
From GTwM
Durward Sobek in his book "Toyota's Product Development Process," calls Toyota's design process "Set Based Concurrent Engineering (SBCE). This process is used to explore the high level design issues in advance of Lean Project Management which focusses on later stages in a project.
Contents |
Theory
Selectivism echoes Charles Darwins theory of evolution with a projects survival echoing the survival of a species.
Instead of fixing a design and then iteratively improving it Toyota engineers start with a range of design alternatives, a set of designs. They don't choose one over the others, rather they maintain the whole set for as long as possible delaying any weeding out process. This reduces the number of design decisions that need to be made. In fact there is no decision. It's all exploration for a long time. Designs which are clearly flawed or unimplementable are eliminated without much discussion and there is actually an elegant process for doing this (described later).
Engineering Notebooks
Toyota engineers narrow their design choices systematically. They want to remove arbitrariness from the filtering process. 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.
Precedence - Roman Law v Common Law
The principles in the notebooks are of this form: "The steel rod cannot be bent beyond X degrees"
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.
Criticism of Incremental Product Development
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.
Completely counterintuitively, 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 & Software Development
So how can SBCE be applied to software? An Agile & Iterative approach can force hill-climbing as the pre-Agile design phase is too short to consider multiple design solutions.
A simple selectivist approach seems to be to accept the need to develop multiple designs at the same time. However, given this could lead to a mess and 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 retains the Darwinian flavor.
Possible Approaches
- Spend some time perhaps a month coming up with feasible designs for solving a software problem. Narrow the set down to say 5. Implement all 5 each iteration and after a few months narrow this down to 3 and then to 1.
- 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:
- Your capabilities: Whatever you cannot implement can be rejected.
- 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.
