The Real-Life Consequences of Complexity

Back in March, John Paul MacDuffie, management professor at the Wharton School at University of Pennsylvania, interviewed Takahiro Fujimoto, an economics professor at the University of Tokyo and a long-time observer of Toyota, about the recent issues Toyota has been facing regarding the recalls of its automobiles.

Under the Hood of Toyota's Recall: 'A Tremendous Expansion of Complexity'

Toyota is the largest automobile manufacturer in the world and has enjoyed a enviable reputation for quality. I think it's fair to say that the issues that it is facing surprised everyone. The edited transcript of the short interview is well worth reading.

Fujimoto places the blame squarely in the management and engineering design realm. He makes it very clear that he doesn't believe the issues are in manufacturing. There is much discussion about how the designers at Toyota are challenged to deal with the ever increasing levels of technical complexity which stem not just from the technologies that they use, but from the demands of their customers and the regulatory requirements of the international markets into which they sell. Fujimoto also implies that there was a significant amount of hubris involved in Toyota's over-confidence in their ability to deal with the complexity.

Although I don't design automobiles, or anything that (as far as I know anyway) goes into an automobile, I do routinely design and implement real-time systems on which peoples' lives depend. It always struck me as counter-intuitive that technical solutions often start out as more complex than they need to be, and only become simpler over time. It is contrary to what you might expect, but in fact it is the simpler solution that takes more time to develop because simplicity only comes with a more complete understanding of the problem by the designer. The overly complex solution is often the first one implemented. As schedules are compressed and budgets tightened, it is frequently the only one implemented.

I see this a lot. It has an impact not only on the consumer of the product, but on the manufacturer's ability to maintain the product over time. Software developers reading this have already realized that this is another manifestation of the need to continually refactor software during development and maintenance. But my observation is that this can still be a hard sell to project managers who, concerned with their schedules and budgets inside their silo or cost center or whatever the faddish term is these days, ask

"And if we do this refactoring, what will the end user see that is different?"

and are told by the technical lead

"Well, if we do everything absolutely perfectly, nothing."

That is not a good way to get work funded.

I wouldn't be surprised if a similar conversation occurred inside Toyota some time ago.