This is a new book by Fred Brooks, the author of much acclaimed Mythical Man-Month. Overall impression: a book of a retired professional who is doing a retrospective of his entire life: recalling how he built a house, how he wrote a book, how he worked in IBM. Such a wonderful, wonderful life. But what does it have to do with most readers who did not happen to know Fred in person, nor visited his marvelous beach house? Nothing. As another reviewer mentions on Amazon, this is a book of wandering mind.
Still, Fred is obviously a distinguished person and listening to him often pays off. But donтАЩt expect to learn any specific technique from this book. There are lots of practical guides on the Internet. The book is a collection of wisdom, most of which, however, I have heard before.
In the first few chapters the book stresses the point that design is iterative process, that it is not possible to get the design right from the very beginning. True. Then he mentions several cases of how the design of complex system was done in a wrong way. For example, designing a military chopper without consulting with pilots. Therefore, even during early design stage it is important that users be taken into consideration. And this is indeed why open-source systems are so successful тАУ because they are driven by users of the product.
Brooks mentions that earlier the designers were actually the users of the product: think of Wright brothers, Ford who rode on the car that he designed, etc. But as the time goes by this happens to change: do you think that space rocket designers are same people as astronauts? Obviously no. And this is going to happen to the software as well, Brooks claims. And I can only add that this is already happening. As a proof I can mention numerous UI frameworks that were designed by UI designers who have little connection with develop teams, not to mention the end users.
Apart from UI design, it is obvious that as the library of software components gets bigger and bigger, the process of building software becomes more like that in assembly factory: take piece labeled S1 and S2, connect them together, wrap them into S3, etc. In such a scenario the designer might not even know how to program. He can use a visual tool to create software. Is this good or bad? I always thought it was good as this makes it possible for people without programming experience to write programs. MIT Scratch is one such example, a hugely popular visual framework not just for kids.
In further chapters of the book Brooks delves into philosophy тАУ empiricism and rationalism. He mentions that abstract math was generated by French philosophers who were mostly into rationalism, whereas applied science was created by Brits who are into empiricism. Brooks claims that software engineering is totally empirical, that is, requires constant verification, and so is the design of software.
Then Brooks sheds light on what are the characteristics of a good design, in his opinion. The major design principles are: orthogonality, propriety, and generality. But those are just general principles. When you design something, you have to make thousands of micro-decisions and the way you make them is called style. How to achieve good style? Brooks mentions the importance of copying other peopleтАЩs styles. He says one can achieve remarkably good results by just mimicking someone else. As an example he cites music: RespighiтАЩs Ancient Dances and KreislerтАЩs Praeludium and Allegro (in the style of Pugnani). Listen to the latter, it is magnificent.
He mentions that even great composers such as J. S. Bach spent considerable amount of time studying other peopleтАЩs works. So, design is a complicated iterative process. As always, documentation plays a very important role. So how can one document the design trajectories? For that tools are needed. Brooks cites a few tools available online, but I cannot say they are mainstream. On the other hand, he fails to mention Mind Maps, a recent tool which is hugely popular among engineers.
To summarize, this book is a message from a successful engineer of previous generation of computer programmers. Can the youngsters learn something from this book? Definitely yes. On the other hand, the book will not fix the problems in existing products, but it can help prevent even more mistakes.