Invention by Design, Petroski

Henry Petroski, Invention by Design
Harvard,1996

Henry Petroski has written a number of books that cluster around the craft and process of engineering. This one sets out to illustrate the inventive process of engineering design. I picked it up hoping to know more about innovation in other fields than my own.

In the ten or so case studies presented, the theme of the problem-as-impetus clearly emerges. Engineers, as critics of existing products, are driven to devise further inventive steps to reach toward a more excellent product. With some exceptions (the Boeing 777 case, which although probably the most contemporary, seemed to be lacking an undefinable quality of fidelity: does he really get what's going on there?), the cases revolve around the thoughts and craft of individuals. In some cases (the drinks can) their identities are obscure, whilst in others (the bridges of San Francisco) they spring from the pages dramatically. Exhibitions of patent documentation provides the bare bones, Henry P re-constructs the whole animal.

It's also clear that teams of engineers, or even distant collaborations, don't simply progress by cutting through an underlying bedrock of physical properties to get to the solution they seek. Rather, at each inventive stage, a higher order product, an improvement from the last, emerges from a mist. Thus we step from toggles to buttons, thence to what must have a been a nightmare of "automatic" clothes-tieing devices, to the zip as we know it. A series of hops then to the Ziplok bag, and yet another string of manoeuvres to Velcro.

But perversely, despite each invention begetting more invention, at the same time each enlargement of the scope and scale of the products seems to make it harder to analyse the next-generation design. Boeing's exponentially growing development budgets attests to this. Not all of the added complexity comes from within the product though, as there are network effects and social or legal changes concerning the use of the products that add further layers of requirement to each iteration.

The idea of resources as enablers, such as materials or tools, for certain types of design activity is also strongly exposed. He exemplifies this all through the book, pointing to CAD as a key technology for Boeing, standardisation for the Crystal Palace among many others. He seems to be too early to notice much use of computing in architecture though.

The chapter on buildings as systems shows how the problem complexity rises with each generation. Perhaps there is an inherent bias in these works, forgetting the industrialisation of innovation in mundane structures. The wonder of the local supermarket, reproduced thousands of times, as opposed to the award-seeking skyscrapers of the capital.

He uses terrorist attacks on the World Trade Center as an example of resilience of design. He refers of course to the 1993 bombs in the basement. What would he make of the later total failure of the designs in 2001, and was this indeed a failure of that particular building as a system, but a failure of a wider, un-designed system?

The J Curve: The Dichotomy of Design and Evolution

Fascinating post on fundamentals to do with Design as we know it vs. emergent paradigms such as GA-driven problem solving.

The J Curve: The Dichotomy of Design and Evolution

Steve Jurvetson is mostly taking about how to do it, how to get a big system off the ground using parts that are designed and parts that are brewed. The interfaces, aargh the interfaces. Every surgeon knows that evolution gives you beautiful functionality but messy interfaces.

Steve presents these two as divergent paths, but I think I'm more hopeful for success in integration of the two styles of technology. I'm not sure why, but I think Layers and Architectures are significant and helpful.

We could add to this another dimension of systems engineering - the Verification/Validation stage. Many of the patterns that have been establisehd in systems engineering rely on transparency of design. Given an evolved system, or even a designed system containing an evolved system, how do you verify the integrity of the system if you can't inspect the drawing or the code?

Or what if the system itself evolves in use, such as an automonous array of communications routers, or a fleet of spacecraft? How can the safety of the users be assured?

We need to look at tending gardens, using animals and employing people for models of how organisations use evolved resources in systems. Track record and training will be as important for machines as it is for people and organisations.

Architectures and Organisation

In this post (and its predecessor) David J Anderson speculates (in his Agile Management blog) on how Lean ideas and product architecture play against each other.

It's pretty obvious I think, that when you have a team of organistions working on a product, some of the decisions about the architecture and interfaces of the product are determined by the organisational structure of the team, and that a different set of partners working on the same problem would develop a different architecture, for management rather than technical reasons. This is entirely legitimate by the way, and working out the best route is part of the function of all technical managers. Sometimes the organisation will be shaped by the product, and sometimes vice versa.

Anderson's thoughts are directed toward Lean, or Agile development, and how that imparts further gradients onto the decision space.