Tuesday, February 28, 2012

Design of Design - Summary of Chapter 15

Chapter 15: The Divorce of Design
  • The Divorce of Design from Use and from Implementation
    • Most appalling development in the design disciple in the 20th century has to be divorce of both the user and the implementer.
    • Several designers back in the 19th century and onwards have invented significant amount of things.
    • However designers can rarely use their own personal experiences as a user, and must seek advice from other.
    • There are exceptions to the divorces, and one exception is software engineering.
    • "Software engineering, for example, is still so young that system architects were once programmers" (Brooks, 176).
    • "The designers of UNIX and especially the Open Source designers of Linux start with their own needs, build tools for their own use, and share with their own peers. I reckon this accounts for both the use success and the user passion" (Brooks 177).
  • Why the Divorces?
    • Advances in the 20th century required specialization and attention from special engineers and in specified time. The implementation was critical in specialization.
    • Some things designed are much more complex and demand a lot of energy from the designer, as well as the cases mentioned above about time and specialization.
  • Fallout from the Divorces
    • Most divorces happen due to miscommunications.
    • "Architects build elegant buildings that are hard to work in" (Brooks, 177).
    • Sometimes communication is poor which can prevent the engineers in knowing exactly what is needed.
  • Remedies
    • Remedy 1: Use-Scenario Experience
      • A small amount of experience is better than not having any.
      • "This “user” experience led to the design of the first operator’s console to be program-controlled (essentially a close-connected terminal) rather than directly reflecting and affecting the hardware, a capability that enables multiple consoles for multiple operators, and a flexible allocation of tasks among operators, as well as online interactive debugging of programs" (Brooks, 178).
    • Remedy 2: Close Interaction with Users via Incremental Development and Iterative Delivery

    • Remedy 3: Concurrent Engineering
    • Remedy 4: Education of Designers

No comments:

Post a Comment