Book review: Thinking beyond lean (Cusumano & Nobeoka)

I originally read Thinking Beyond Lean (1998) over four years ago, it was good at the time and its still good. A few weeks ago I picked up the book to check something and decided it was worth a re-read. Four years ago I didn’t know as much as I do now about lean production and lean product development so I thought it would be worth another look.

The book is a study of how car companies develop their products, and specifically, how they reuse the designs to product additional products, e.g. the Ford Mondeo in Europe is the Ford Contura in America and a Jaguar something in both places. Of course, as you might guess from the title Toyota is the pace setter in this field as in so much else.

I did write about the book after my first reading and still agree with what I said then, there is good advice here we can apply to software development.

The book is interesting for two reasons. First it is an interesting insight into product development at some very companies. Second it looks at the subject of reuse in a context of multi-project management.

Make no mistake, the car industry has problems reusing its designs. Reuse is difficult. The overriding lesson is: reuse doesn’t just happen, you have to arrange for it to happen.

Cusumano and Nokeoka do identify four models of reuse, or rather four models of design, three of which are reuse and I think its worth naming them here:

• New build: design something new from the start, even if you could reuse something there are good reasons why you might do this.
  
• Concurrent: two or more projects running concurrently developing new products, usually one is the lead project
  
• Sequential: design something new, leave it alone for a while then try to reuse it for a new product.
  
• Design modification: design something new, leave it alone for a bit then come back and tweak the design for a new version.
  

Four years ago I thought these models were useful in describing software development and I still do. However, the software industry doesn’t think like that. We have four models of our own:

• Framework: we create a project that has no objective but to create a platform for others to reuse. Usually these projects are expensive and often they fail.
  
• Reuse will just happen: made famous by the OO movement, the idea is that if programmers write “objects” (later components, now SOA components) then somehow they will be usable by others.
  
• Cut-and-paste: probably the most widely used; our own version of design modification.
  
• Packaged: we buy something someone else has written and work with it through an API.
  

I think only the last of these can really be claim to be a success.

There are lots of reasons why a reuse attempt can fail but mostly they boil down to organization. So, to make reuse happen you need to get the organization right - we’re back to Conway’s Law!

But there are other reasons, e.g. accounting. If project B is six months behind A and reuses their designs then who pays the bill, A or B?

And reuse may not always be a good thing. If you are competing on innovation then continually reusing your existing products may stop you creating innovations. It may also stop you from producing distinctive products - one of the problems Volkswagen had when it got very aggressive about platform sharing.

Yet another problem, not mentioned in the book, is your product life cycle: if all your products use they same platform then they will all age at the same pace and will all need replacing at the same time. So, just when your cash flow is low (because all your products are old) you will need to spend a lot replacing them.

I think the main difference in reading the book four years ago and today is my own scepticism about reuse. Four years ago I still believed we in the software industry could do it, all we needed was the right approach. Now I’m not sure. I think the level of complexity in software is so great trying to product something for reuse isn’t worth the effort in most cases.

That said, if the software industry is to make any headway here we need to take on the issues and lessons described in Thinking Beyond Lean .