Mythical Man Month

In 1975 Fred Brooks wrote what has become a seminal book in software engineering, The Mythical Man Month.

In this book he presents several ideas and observations related to how people develop and engineer software, many of these ideas are still talked about and debated today while we continue to try and learn the lessons that Brook's experiences detail.

I will not attempt to cover all the subjects dealt with in the book but I will present what I feel are some of the reasons why this book is held in such high regard.

Brooks's Law

Central to the book is the presentation of Brooks's Law:

"Adding manpower to a late software project makes it later."

The point here is that attempting to reduce software development planning to the simple mathematics of the amount of work one engineer is capable, of multiplied by the number of engineers, while potentially appealing is ultimately false accounting.

The main reason for this is that it discounts the need for the engineers to act as a team rather than purely as individuals.

Writing software of any significance is a complex business that doesn't lend itself to being sub-divided into well formed tasks that can be worked on in isolation.

Instead engineers will be required to communicate with each other to ensure the many moving parts being developed will be able to be coalesced into a working machine.

For this effective communication to take place a level of knowledge about this end goal and the blueprint for getting there must be inherent in the team, introducing new team members weakens this collective understanding and is a distraction to the team while they bring these new members up to speed.

Irreducible Errors

Brooks makes the observation that in any reasonable complex system there is a tendency towards an irreducible number of errors.

"99 little bugs in the code, 99 little bugs, take one down, patch it around, 127 little bugs in the code."

That is to say that the outcome of fixing one bug maybe to cause bugs in other errors, or that solutions to fix complex bugs in themselves may contain bugs.

This implies that there is a need to manage bugs in a code base rather than to have an unrealistic expectation to eradicate them entirely.

The most important aspect of this being to manage the impact of bugs and to understand those that exist to inform analysis and to formulate plans to fix the most critical without causing equally undesirable consequences to be accidentally implemented.

This also breeds a healthy mindset to expect the code to fail and therefore to build in the automated testing, diagnostics and analytics to enable this failure to be detected and ultimately managed.

Conceptual Integrity

A system should be about more than simply the sum of the various aspects of its implementation, it should in fact implement a concept of functionality that needs to be delivered to end users.

Once this concept has been established it should be guarded and protected, just because a system maybe capable of doing something doesn't mean it should.

Often functionality maybe able to be put to novel or inventive uses but if this violates or does not comfortably sit with the original concept of the system it could potentially degrade users interaction with it by introducing complication or by simply not being discovered by them.

This ultimately leads to a mindset favouring simplicity with relatively complex systems being built over time with users being guided at each stage so they maintain their understanding of what the system is for and how it can be used.

This simplicity and gradual journey towards more complexity will also help the problems of estimation and errors that we've previously discussed as a simpler system is not only easy to use its easier to work on and maintain.

As much as things change in software development they also stay the same, many of the teachings that formed the bedrock of early forays into the art form are as relevant today as they were when they were first written.

Make sure you learn these tried and tested lessons even if the languages and techniques used at the time may not be inline with your current work stream, the fundamental truth of these observations will still hold true.