Meeting once more in Far from the Madding Crowd, there were more of us in attendance than last time. In addition to Chris, Steven and myself from the first meeting, we were joined by John, Miquel, Jim and Stephen.

We began with Chris pointing out how the book described another world of programming to that we were familiar with, the 60s and 70s of Brooks’ experience. A place where documentation could be measured in feet, where secretaries could potentially be typing up the alterations to a new version of a manual every day. Where hardware development was a lot closer to software development. This perhaps was a barrier of entry in terms of understanding for some of the more esoteric parts of the book.

It was then mentioned how the language of the book was not always clear. For instance:

One rarely controls the circumstances of his work, or even its goal. In management terms, ones’ authority is not sufficient for his responsibility. It seems that in all fields, however, the jobs where things get done never have formal authority commensurate with responsibility
P8 The Mythical Man-Month

This was a confusing concept for us, perhaps as we all mainly seem to be used to working in small teams, and responsibility being much closer to us the majority of the time

We talked about the concept raised by Brooks that with manufacturing, if there is an error with a product, it is quickly apparant what is to blame. In software development it is harder to find the blame. It was pointed out by both Jim and Chris that it was in fact very easy, you just blamed Microsoft, Oracle, Apple, a passing DBA, anyone or anything.

Chris brought up the point he made previously on this blog about how Brooks seemed to use the terms Debugging and Testing interchangeably. Steven commented that it was possible that in his day, the only way of testing could reasonably have been to run a program through a debugger.

The Surgical Team suggested as an ideal in the book (p36) was suggested as obviously overkill in this day and age. A lot of the functions that were covered by individuals in this team are now automated, such as properly self-documenting programmes. However, I pointed out that the concept of having a pilot and a co-pilot, with the co-pilot checking the pilot’s code, sounded an awful lot like paired programming, just without switching the roles regularly. It certainly accepts the principle that even allowing for a “superstar” programmer in charge, that their code can only benefit from peer review, a second set of eyes.

Staying with the concept of teams, Miquel raised Brooks’s Law

Adding manpower to a late software project makes it later
P25

Which was felt to be a fairly obvious point, made even more obvious by his later clarification that this did depend on the skill of the people you added. Again though, it was clear from our discussion that as we all come from smaller teams, we are not used to the needs of a significantly larger project. Brooks himself does suggest that the ideal is a small team of experts, but in order to get a large project to completion, more often you will require a large team of a range of quality, in effect arriving at an appropriate solution through more volume and brute force than from skill and design.

Mention is also made of being prepared on the design side to design your initial model, and then to throw it away in favour of a better model once you have more knowledge of and familiarity with your project. Whilst this concept of not being tied to the initial model is reflected in an XP approach, XP suggest a refactoring approach of constantly improving the model.

Moving on to the essay No Silver Bullet, perhaps the concept that most irked Chris and myself was the following statement:

I believe the single most powerful software productivity strategy for many organizations today is to equip the computer-naive intellectual workers on the firing line with personal computers and good generalized writing, drawing, file and spreadsheet programs, and turn them loose.
P199

I have spent too much time in my days in support dealing with accidently deleted files, user-imposed password protection on documents belonging to left users, and a myriad of poor design choices to agree with this. I described this approach as “Let them eat Excel”

Jim brought up the somewhat pessemistic tone of the whole book, that there truely was no silver bullet, and that these words do firmly hold true today. We discussed several potential silver bullets of the past, and that the general fault, as identified by Steven, was that they often tended to be great solutions as long as what you wanted them to achieve was within the narrow design remit they had assumed, and that as soon as you needed something outside of this remit, the amount of work required to get around the restrictions would almost always outway the benefits you had initially gained.

The comment of Martin Fowler that “You can’t measure productivity” was brought up in the context of Brooks’s attempts to do just that. This was in an age where productivity was being measured in terms of words written in code, rather than lines of code written. However, reflected in the light of refactoring, code could also be judged in terms of lines removed, of the brevity of the code. The smaller and neater the better, in some regards.

Chris brought up the concept from the book that Maintenance was Decay:

All repairs tend to destroy the structure, to increase the entropy and disorder of the system.
P122

This again doesn’t equate to the improvements one would expect from incremental design and refactoring, so was quite an alien concept to us. However most agreed that the concepts from the book that were still relevant were the issues of communication and team work Brooks describes. Possibly where the technical aspects of software development have constantly developed for decades, the principles of teams, management and organisation are slower to move on, having been around for much longer.

I think it is fair to say that we deliberately read this book from a modern point of view, and in some cases were reading it against some of the principles of XP and Agile development. So we were likely to be more critical, and we were. However it was also apparent that some aspects of developement are still as Brooks suggested, and that some ideas for XP and Agile were slightly foreshadowed by him many years before.

All in all, a successful meeting, more attendees, and a lot of ideas and points were raised by everyone, and I look forward to see what we make of our next book

Please feel free to correct me on any inaccuracies in my recollections of our meeting, or to discuss the points I have recorded.