Readme. 'The Mythical Man-Month' by Frederick P. Brooks Jr.

 

Readme. 'The Mythical Man-Month' by Frederick P. Brooks Jr.

I have recently finished reading ‘The Mythical Man-Month: Essays on Software Engineering’ by Frederick P. Brooks Jr. The first edition of the book was published in 1975, the version that I have is the 20th anniversary edition (it has a few additional chapters).

Curiously, the points made in the book aren’t as out-dated as you would expect, but, I suppose, that’s because, as Brooks himself explains it, ‘The Mythical Man-Month’ is mostly about managing people and processes, which don’t change that much. The examples he frequently uses are from his IBM days, when he worked on things like OS/360 (1966), so pretty old stuff, but an interesting read nonetheless. Some of his examples get a bit too low-level for my taste, some are hardware focused, but, overall it kind of works, because, like I said, it’s less about those specific cases and more about work organisation.

I think it’s a good book, I think a lot of it makes sense and should be checked out. It establishes a solid base that you can then build upon by stacking more modern work organisation techniques on top, stuff like Agile methodologies, clean code, good documentation, etc.

Here are the chapters with brief-ish descriptions of each.

Chapters

The Tar Pit

This chapter compares large systems development to a tar pit, exploring why some types of development can produce quick, tangible results in a relatively short amount of time with only a couple of people working, while other can take years for dozens or hundreds of programmers to complete. The author discusses the difference between a program, a programming product, a programming system and a programming systems product and why they all require different approaches. The chapter finishes with a discussion on joys (creating useful things, solving puzzles, learning, etc.) and woes (bugfixes, code obsoletion) of programming.

The Mythical Man-Month

‘Good cooking takes time. If you are made to wait, it is to serve you better, and to please you’

The chapter focuses on why estimations frequently fail: poor estimation techniques, the assumption that effort means progress, lack of understanding that a good implementation of a product requires time, poor monitoring of schedule progression, the fallacious assumption that if the schedule is slipping - throwing more people at the problem will fix it.

The Surgical Team

This bit explores two different approaches to system building: having a highly specialised, small, sharp team of professionals; or a large group of hundreds of programmers whose knowledge and performance is average. To analyse the problem, Brooks looks at the history of creating OS/360, which was developed by a team of 200 people. He makes some assumptions about potential performance of a surgical team versus the 200 people team, performs some calculations and shows that, while it is highly plausible that a specialised team would have required less overall person-hours to complete the project, it would have still taken longer (in terms of calendar time) simply because there’d be a lot less people on the team. So, really, the question here is: would spending more calendar time on a project affect whether the product is obsolete or not by completion time? Is it needed urgently or can it wait? The suggested solution - split a large job into contained segments, assign a small team to each segment. Brooks then talks about specific roles that would need to be covered within these teams.

Aristocracy, Democracy, and System Design

The chapter discusses conceptual integrity of a product and potential strategies of achieving it. One of the approaches advised is a careful division of labour between architecture and implementation. There should be few architects and it’s them who are in charge of the overall vision, external specification; architects shouldn’t provide any specifics on exact implementations, which gives the people implementing the solution creative freedom in their part of work.

The Second-System Effect

This chapter talks about the pitfalls of creating a second system. The assumption here is that the architect working on their first system is usually cautious, they are aware they don’t know what they are doing and do their job carefully and with restraint. During work on the first system the architect gets a myriad of ideas that they think would be nice to implement in their next project. So when they do devise their second system it turns out to be an explosion of ideas and features that lack consistency and even reason to be there.

Passing the Word

‘Passing the Word’ talks about the ways managers can communicate the architects’ decisions to everyone within the team. The suggested means towards clear communication are:

  • Having a written specification (the manual);
  • Usage of both prose and formal definitions - one should be made the standard, the other - a derivative description (doesn’t matter which one is which, as long as it’s consistent). Note: an implementation can serve as a formal definition;
  • Weekly half-day conferences and annual or half-yearly two-week-long court sessions;
  • Having multiple implementations of a project promises cleaner definitions in the manual;
  • A log of all Q&As accumulated during the development process, compiled weekly by architects;
  • Services of an independent product-testing organisation to find gaps in the manual in the process of testing.

Why Did the Tower of Babel Fail?

In a way, this is a continuation of the previous chapter. It talks about the challenges of communication in a large programming project, talks about what a project workbook is, why it is needed, and the mechanics of implementing it for teams of 10, 100 or 1000 people. The chapter wraps up with a discussion on how one would organise a large programming project and the differences between the roles of the project’s technical director (making technical decisions) and producer (mostly administrative work).

Calling the Shot

Here Brooks talks about the ways of measuring programming effort and estimating time it will take to produce a piece of work. It is stated in the chapter that one of the main estimating problems is that people doing the estimation usually look at the amount of time it will take to perform a job, without taking into account downtime, meetings, paperwork, higher-priority short unrelated jobs, company business, sickness and holiday. Another thing mentioned - the bigger the team the more time will be spent on communicating all the necessary information between its members.

Ten Pounds in a Five-Pound Sack

This chapter talks about taking the size of the product into account during development so that memory usage of the final product isn’t too costly. There is a section on size control, which states that it should be defined what a module must do when specifying how big it must be; clear communication between the members of the team should be established, so they can have a clear idea of the performances of different aspects of the system. There is also a section on techniques that can be put to work for more efficient space use.

The Documentary Hypothesis

In this bit Brooks talks about documentation, specifically which bits of it are genuinely useful (objectives, specs, schedule, budget, etc) and which are a waste of time and effort. He covers documents needed for a computer product, a university department and a software project, drawing attention to similarities. The final section explains why having formal documents is essential (a better understanding of the implementation; a means of communicating information across the team, a way to see if the project is on track).

Plan to Throw One Away

The suggestion here is that in many projects the first system built is barely usable (too slow, big or awkward to use), so it is best to note lessons learnt during its development and throw it away. Making the badly written system faster, more usable, fixing the bugs, maintaining it - is more likely to take more time and effort than using the found knowledge to create it anew. Accepting that the first implementation is not ideal and isn’t there to stay allows to plan the system and organisation for change.

Sharp Tools

This one is about tools that are needed to effectively and efficiently work on a project. The tools mentioned go from high level to low level and are: a computer facility with target machines and an established machine scheduling philosophy; operating systems and service philosophies; a language with a defined language policy; utilities; debugging aids; test-case generators; text-processing systems for documentation.

The Whole and the Parts

Brooks talks about minimising the amount of bugs through design, by bug-proofing the definition, testing the specification through an outside testing group, implementing top-down design and performing structured programming. He then dedicates a few pages to component debugging, specifically: on-machine debugging, memory dumps, interactive debugging and test cases. After focusing on component debugging, Brooks moves on to system debugging and talks about: use of debugged components; dummy components, data and auxiliary programs, controlling changes, adding one component at a time and quantising updates.

Hatching a Catastrophe

‘Hatching a Catastrophe’ is about ways of controlling and minimising schedule slippage. The first step is to actually have a schedule with well-defined, concrete, sharp-edge milestones. Recognising and acting upon one-day slips is important, since, when ignored, they tend to accumulate into massive chunks of time lost, which can turn out to be especially disastrous if the slip has occurred on the critical path. Brooks recommends using a PERT chart to keep an eye on critical paths and schedule slippage. The other problem discussed is that first-line managers might be reluctant to talk to their boss about schedule slippage. The assumption being that the boss might take action that will preempt the manager’s function and diminish their authority. Brooks suggests two strategies:

  • Reducing the role conflict. The boss recognises the difference between information requiring action and status information and never acts on problems when reviewing status;
  • Arranging regular reviews of the PERT chart and its milestones.

The Other Face

This chapter focuses on the necessity of good documentation. Brooks talks about ways to instill the right approaches to writing documentation. His opinion is - it’s more useful to demonstrate how it’s done by example, rather than talk about how it should be done.

The chapter mentions different levels of documentation:

  • A prose overall description of the program, taking up to 3-4 pages.
  • A description of how one can tell that the program is working correctly. So, test cases.
  • If a program can be modified (adapted or fixed) by the user - documentation should contain in-depth information on its internal structure.
  • Self-documenting programs - a merge of documentation and source code. Readable comments, descriptive variable names, if the need arises - the flow of instructions can be represented by arrows in comments alongside code.

No Silver Bullet - Essence and Accident

This chapter talks about the lack of technological and management techniques that can, by themselves, promise massive improvements in productivity, reliability and simplicity. Brooks talks about some of the proposed silver bullets and why they don’t work. The chapter is part of the older version of the book, having been written in 1986, so some of the things mentioned in it do look outdated, however, they do provide an interesting glimpse into the past of software development.

“No Silver Bullet” Refired

The chapter was added in the 1995 edition of the book and it revisits the previous chapter, taking a look at what has changed in the past 9 years: which of the predictions failed and which didn’t. It also addresses some of the criticisms towards the original ‘No Silver Bullet’ chapter. In addition, it mentions things that can have some positive effect on productivity, simplicity and reliability, such as high-level languages, object orientation and writing code for reuse.

Propositions of The Mythical Man-Month: True or False?

Here, Brooks very briefly summarises all 15 chapters of the original 1975 edition, and, looking at them in 1995, provides his opinion on which of them he believes to still hold true and which have been disproved or made obsolete. Done in a very condensed manner - a sentence or two per each section of every chapter, sometimes accompanied by a short comment.

The Mythical Man-Month after 20 Years

This is the final chapter of the book, where Brooks addresses some of the questions he’s been asked since the book was first published in 1975: ‘What do you now think was wrong when written? What is now obsolete? What is really new in the software engineering world?’. I feel like this chapter is a more conversational version of the previous one.