Wednesday, September 08, 2010

Rereading Mythical Man month

Recently I started rereading Mythical Man Month by Fred Brooks. The book is a collection of essays about programming and software development in general. First edition was published in 1974. I am reading the 20th Anniversary edition published in 1994. So the one I am reading is also 16 years old.

First time I read this book sometime in year 2000. At that time, I was a just a somewhat experienced developer. In last 10 years, I have handled teams, worked in project leader roles, taught software development, design, architecture.  Now when I started rereading the book, its a very interesting and educational experience. Some things which I did not completely understand or believe at that time, now those ideas make sense. Though the ideas and advice in the book are still very sound advice even after 35 years. Still this book  is known as a book 'that is quoted often but followed rarely'. I agree to that.

I am going to review some ideas on the book which stuck a cord.

I found a following gem in Chapter 13, The Whole and The Part. Here Author is talking about the 'System Debugging'. 
Build Plenty of Scaffolding
By scaffolding I mean all programs and data built for debugging purposes but never intended to be in the final product. It is not unreasonable for there to be half as much code in scaffolding as there is in product.

One form of scaffolding is the dummy component, which consists only of interfaces and perhaps some faked data or some small test cases. For example, a system may include a sort program which isn't finished yet. Its neighbors can be tested by using a dummy program that merely reads and tests the format of input data, and spews out a set of well-formatted meaningless but ordered data.

Another form is the miniature file. A very common form of system bug is misunderstanding of formats for tape and disk files. So it is worthwhile to build some little files that have only a few typical records, but all the descriptions, pointers, etc.
I suddenly realized that the description is very similar to description in Agile books/articles about Test Driven Development. (with some minor change in terminology). 'dummy component' is Mock Objects. The estimate of proportion of 'test code' to 'production code' is also very similar('It is not unreasonable for there to be half as much code in scaffolding as there is in product' )

I found few more such gems. Later I will write about them.