In The Design of Design, Frederick Brooks takes aim at the problem facing every engineer and designer: how do you architect and build a complex system? The question is especially pertinent to computer scientists and programmers. Below are a few notes from the book.
The Waterfall Model is wrong. Not only because it limits the flexibility of design, but also because it so poorly describes how development actually happens. It is inaccurate and crude, and does not promote good design. But all is not lost. Even though the Waterfall Model is a poor choice, a design methodology can be valuable. It guides the design process and gives structure to team collaboration and communication.
Brooks discusses several software design methodologies, ultimately backing to the Spiral Model. This model closely matches how many teams actually work. The Spiral Model starts with a definition of the system’s core concepts and objectives, spiraling out into mockups, prototypes, and finally an operational product. It suggests an evolving “outward” process flow, guiding the product “out” into production. It also articulates the consistent need for review and risk assessment at each stage of an iterative process.
Although these models are useful for guiding the design process, a Chief Designer needs to be at the core of the process to ensure conceptual integrity of the design (language, interface, visual design, and so on).
The user interface, the users’s crucial system component, must be tightly controlled by one mind. … In large architecture teams, the chief architect’s scope is too large for him to do the interface himself. Nevertheless, one person must do it. If one architect can’t master it, one user can’t either. (p 72)
The best products are always spearheaded by one or two visionary thinkers: consider the greatness of the Macintosh, UNIX, Python, FORTRAN, etc, versus the lackluster PC, Windows, Appletalk, or Cobol. Brooks then argues that it is the role of supporting management to get out of the way of the Chief Designer and her team, giving the designer ultimate authority on design decisions, protecting the team from unnecessary meetings and interruptions, etc. to encourage flow and creativity.
Great designers articulate user profiles. A written description of each kind of user helps to discover and define assumptions about the design, and guides the entire team.
Great designers also actively research the work of other great designers. An anecdote:
Bach took a six-month unpaid leave from his job and walked 250 miles to study the work of Buxtehude. (He lost his job for overstaying his leave.) Bach proved to be a much greater composer than Buxtehude, but his surpassing excellence came from comprehending and using the techniques of his predecessors, not ignoring them. (p 154)
Finding exemplars in the field of computer science is not hard, but few programmers today take the time to read code and investigate systems. More could be done to encourage students, especially, to research the excellent work done by their predecessors.
The Design of Design is highly recommended. It provides a wealth of information about the design process from someone who has designed beautiful systems (and some not-so-beautiful), with plenty of real-world examples and insights. A must-read for anyone who is designing software.