Book review: The Design Of Design

Its a well written and substantial book.  Deep personal experiences and clear writing style make it a winner.

I tried to outline the essence of the book here.  If you are like me, you can use this as checklist to see areas of      improvement in your project.

Waterfall model:  Explores the origin of the model and confirms the widely help notion that it does not mirror real experience in the field.  Recommends that we outgrow it.

Design is not just design:  Realizing that software design is not just about building software – its about helping your client discover what he/she needs.

Requirements: Discusses some famous project including the Comanche helicopter and the IBM 360. Strongly against design by committee. Highlights the need for a technical voice to be involved at the highest levels, right from the onset. This person would help balance function against schedule and cost.

Team design: Movement of design from being a solo activity to firmly being a  team activity. The reason being

  • Growing complexity of the sub disciplines make it difficult to be master of all
  • Speed to market – unfortunately like great designers of the past companies usually cant take years to deliver

This collaboration comes at a cost. More overhead in keeping everyone at the same conceptual level. The risk of loosing conceptual integrity. His advice is to have

  • A System architect who must ensure that the team sticks to the vision and the product is consistent.
  • A UI designer – similar role as the System architect except that this person is the guardian of a consist UI.

Telecollaboration: Explores the effectiveness of various telecollaboration technologies.

Concludes that face time beats everything else. The time and money invested in travel is well worth it. Cites an interesting example of Boeing flying its design teams for the 777 plane so that they could work together for weeks at a time !

Touches on attempts to use something like Second life for virtual collaboration. Certainly an interesting idea !

Know your user: Understand and capture who your target user is. How is he/she intending to use the product ? In this process if we realize that our user models are incorrect its still better than working with unclear user models.

What you don’t know about your user ? Makes a points of clearly capturing assumptions made about the user model. More confusion avoided.

The budgeted resource: Every project has one thing which is most important for it – speed, bandwidth, memory usage, computation accuracy etc.  This one thing should be know to the whole team. The design should always carefully take this into account – conceptual integrity.

To be continued ..


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s