January 8, 2011
The book is 35 years old and it shows in many places. What is fascinating in the book is not so much the solutions that they came up with at that time (obviously some technology hasn’t been around at that time), but that many of the problems they faced are still problems today.
For example in the chapter “Why did the tower of Babel fail?” he writes:
“So it is today. Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn’t know what the right hand is doing. As work proceeds, the several teams slowly change the functions, sizes, and speed of their own programs, and they explicitly or implicitly change their assumptions about the inputs available and the uses to be made of outputs.”
His suggestion to using the telephone often, regular project meetings and a (physical) workbook (that needs to updated by each engineer) are outdated of course. However it is interesting to see, that he pointed his finger on a big problem that is still valid today. We’re still looking to solve that. In the meantime, a lot of things have addressed these concerns: Javadoc, Wikis, Design by contract, Unit tests etc.
So if you decide to read this book and expect to get solutions out of it, you will probably be disappointed. But you will be amazed, that many of the big problems from back then are actually still big problems today. Even more, they seem to be problems that still catch projects by surprise as they rediscover them. In that regard, the time spent reading this small book is time very well spent!