Skip to content

Instantly share code, notes, and snippets.

@dariodaich
Last active October 23, 2016 19:10
Show Gist options
  • Save dariodaich/0e6eaec767476464290c678282635273 to your computer and use it in GitHub Desktop.
Save dariodaich/0e6eaec767476464290c678282635273 to your computer and use it in GitHub Desktop.

The Mythical Man-Month - go-to book summary

The following is the summary of the Mythical Man-Month aka MMM, the book that needs no introduction. It is a must-read for every participant of any software development process.

Insights sections include my personal realizations derived from the material read and are essentially a collection of a-ha moments.

7. Why did the tower of Babel fail? (p. 73)

Communication in the (Large) Programming Project (p. 74)

  • ways of communication on the project:
  1. Informal
  2. Meetings
  3. Workbook

The Project Workbook (p. 75)

  • What: the project workbook is a structure of documents designed in such a way that facilitates communication among the team. All project documents need to be part of it.
  • Why:
  1. base of any future document devised from any project documents
  2. control of the distribution of information

Organization in Large Programming Project (p. 78)

  • Tree-like programming organization:
  1. mission
  2. producer
  3. technical director or architect
  4. schedule
  5. division of labor
  • Three basic relationships:
  • The Producer and Technical director may be the same man
  • The Producer may be boss, the Technical director right-hand man
  • The Technical director may be boss, and the Producer right-hand man

Organizations must be designed around people available; not people fitted into pure-theory organizations.

The job done least well by project managers is to utilize the technical genius who is not strong on management talent.

The techniques of communication and organization demand from the manager much thought and as much experienced competence as the software technology itself.

10. The Documentary Hypothesis (p. 107)

The Hypothesis: Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools.

Small set of documents embodies and expresses a lot of managerial work. The preparation of each such document serves as a major occasion for focusing thought and crystallizing discussions that would otherwise generate confusion instead. That kind of document is regularly maintained and it serves as a checklist and a status control.

Documents for a Computer Product (p. 110)

  • Objectives
  • Specification
  • Schedule
  • Budget
  • Organization chart
  • Estimate, forecast, prices

The concerns for any management task are what, when, how much, where and who.

No matter how small the project, the manager must create and formalize mini-documents in the earliest phase to serve as his communication base, creating information boundaries at the same time.

Conway's Law Organizations which design systems are constrained to produce systems which are copies of the communication strucutres of these organizations.

Why Have Formal Documents? (p. 111)

  1. writing down decisions and information is essential. Only when one writes, gaps in logic and requirements protrude.
  2. "the documents will communicate the decisions to others." Policies communicated this way will fill the gaps in the knowledge of all team members. Fundamental goal of the manager is keep everybody going in the same direction. Meaning, his main daily task is communication and not decision making.
  3. they provide a database and a checklist which help him to steer the project in the correct direction.

About 20% of the executive's time is spent on tasks where he needs information from "outside his head". Everyhing else is related to communication:

  • hearing
  • reporting
  • teaching
  • exhorting
  • counseling
  • encouraging

"But for the fraction that is data based, the handful of critical documents are vital, and they will meet almost all needs".

Manager's task is to develop a plan and then to realize it. Only written plan is precise and communicable. It envelops documents on what, when, what budget, where and who. If created in the beginning of the project and continually revised and build upon, it becomes manager's "virtual assistant", instead of cumbersome mountain of files which increase his daily (congnitive) load.


Insights

Large number of project documentation is useless. Useless documents constitute "Dead documentation". The one that adds complexity, occupates space and is not read at all. It exists to create imitation of real work done and induces false sense of security and control. If outdated, it will most likely add confusion and mislead readers.

Its antonym is then "Living documentation", which in contrast has to be:

  • intuitively and clearly organized
  • clearly and unambiguously written
  • read daily
  • give answers
  • point to right questions
  • revised and maintained frequently

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment