Book Notes: The Mythical Man Month: Essays on Software Engineering

Overview

This post contains my notes on the book Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton, Manuel Pais, and Ruth Malan.

You can find the book on Amazon

I’ll be adding my notes to this post as I read through the book. The notes will be organized by chapter and will include key concepts, code examples, and any additional insights I find useful.

Chapter 1: The Tar Pit

Programming Systems Product

Programming Product costs ~3x as much as a debugged program w/ same function

The Joys of the Craft

Making Things
Making things that are useful
Fashioning complex puzzle-like objects
Always learning
Delight of medium

The Woes of the Craft

Perfection
Other people’s objectives
Other people’s systems
finding bugs is work
product appears obsolete before finished

Challenge and Mission: to find real solutions to real problems on actual schedules with available resources.

Chapter 2: The Mythical Man-Month

Calendar Time Causes Issues

Estimating is poorly developed
Estimating techniques confuses effort with progress
Estimates are uncertain
Schedule progress is poorly monitored
Natural Reaction to Schedule Slippage is to add manpower

Optimism: All programmers are optimists

Creative activities:

idea
implementation
interaction

Incompleteness and Inconsistencies become clear during implementation.

The man-month

Cost = # of programmers * number of months

The bearing of a child takes 9 months, no matter how many women are assigned.

Project Planning Rules:

1/3 Planning
1/6 Coding
1/4 component/system test
1/4 system test

Gutless Estimating

Develop and Publicize productivity Figures
bug-incidence figures
estimating rules

Brook’s Law: Adding manpower to a late software project makes it later.

Chapter 3: The Surgical Team

Team Composition

1 Surgeon: chief programmer, system architect
1 Co-Pilot: backup programmer, assistant architect
1 Administrator: handles clerical work
1 Editor: proofreads documentation
2 Secretaries: handle typing
1 program clerk: maintains program library
1 Toolsmith: builds and maintains programming tools
1 Tester: designs and runs tests
1 Language Lawyer: expert in programming language

Surgeon and Co-Pilot do all design and coding
Surgeon makes unilateral decisions

Chapter 4: Aristocracy, Democracy, and System Design

Conceptual integrity: system has a single, consistent design approach

Most important consideration in system design
Purpose: Ease of use

Ratio of function to conceptual complexity: test of system design

Aristocracy and Democracy

Conceptual Integrity -> design from one mind, or from a very small number of agreeing resonant minds
Scheduling Pressures -> Many hands

division of labor between architecture and implementation
structure programming implementation teams (surgical teams)

Separation of architectural effort from implementation effort is essential to conceptual integrity for large projects.

Architecture: Complete and detailed specification of the user interface
Architect: user’s agent, professional/technical knowledge
Architecture: What
Implementation: How

Good features/ideas that do not integrate with the system should be dropped.

Chapter 5: The Second-System Effect

Architect: works against a budget Iteration: bids->estimation upward, design downward

High Estimate:

cut the design or
challenge the estimate by suggesting cheaper implementations

things to remember:

builder has inventive/creative responsibility -> suggest, not dictate
suggest a way of implementing anything specified, accept any other way to meet objectives
deal quietly and privately w/ suggestions
forgo credit for ideas suggested

Self-Discipline

First Work -> Spare and Clean Second system -> tendency to over design

Chapter 6: Passing the Word

Written Specifications

Manual: External Specification

describes and prescribes every detail

Formal Definitions

precise definitions

A programmed simulator can be used as a formal definition

Conferences and Courts

Meetings are necessary

Weekly half-day conference of all architects
- propose problems/changes distributed in writing
- discuss and decide
- chief architect decides if no consensus
- minutes kept and distributed
- appeals possible
Annual court session
- two week long meeting
- backlog of minor appeals, open issues, disgruntlements

Benefits:

same group: no time needed to bring people up to date
well versed in project: better decisions
deeply involved in outcome
problems -> solution within boundaries
formality of proposals focuses attention and forces decision
vesting of decision in chief architect avoids compromise and delay

Telephone Log

Record each question and answer
Logs of architects are concatenated, produced, and distributed weekly

Product Test

independent technical auditing group
customer is independent auditing group

Chapter 7: Why Did the Tower of Babel Fail?

A successful project needs:

Clear Mission
Manpower
Materials
Time
Technology
Communication
Organization

Options for communication:

Informal: Telephone service, clear definition of intergroup dependencies
Meetings: regular technical briefings
Workbook: written records of decisions

Project Workbook:

What: structure of documents
Why:
1. early design of structure ensures structure is crafted
2. control of distribution of information
Mechanics:
1. Everyone should have access
2. Timely updates
3. Continual Maintenance: diff of change, summary of changes

Organization:

Purpose: reduce communication/coordination overhead
Principle: No man can serve two masters
Organization: division of labor + specialization of function
Organization subtree need:
1. mission
2. producer
3. technical director/architect
4. division of labor
5. interface definitions among parts
Role of Producer:
- assembles team, divides work, establish schedule, acquires resources
- Establishes communication outside team, upwards and sideways
- Ensures schedule met, shifting resources and organization
Role of Technical Director/Architect:
- conceives design to be built, identifies sub-parts, specifies how it will look
- unity and conceptual integrity
- invents solutions and shifts design to solve technical problems
Producer could be the same as Technical Director/Architect
- strong management and strong technical talen is rarely found in one person

Rare: Thinkers Doers: Rarer Thinker-Doers: Rarest

Producer might be boss w/ director as right hand
Director might be boss w/ producer as right hand

Chapter 8: Calling the Shot

Estimating

What not to do:

estimate coding portion and apply ratios from earlier
errors in the estimate or ratios could lead to large errors in schedule

small program estimation != large program estimation

Estimating misses often due to missed:

short unrelated jobs
meetings
paperwork
company business
sickness
personal time

Productivity = thought per statement + errors it includes Productive time = x5 when high-level language used

Chapter 9: Ten Pounds in a Five-Pound Sack

Program Space as Cost

Size is a large part of the user cost of a programming system product

Size itself isn’t bad, but unnecessary size is.

Size Control

Project Manager: size control = technical and managerial

budget for all aspects of size set total size budgets as well as space budgets for major components
Define exactly what a module must do when you specify how big it must be.
Total-system, user-oriented attitude may be the most important function of the programming manager

Space Techniques

Space Budgeting + Control != small program small programs require invention and craftsmanship

Space time tradeoffs

ensure team is trained in programming technique
recognize programming has a technology and components needs to be fabricated

Representation is the essence of programming

rethinking the overall strategy (especially how data is represented) instead of code tricks can lead to innovation

10: The Documentary Hypothesis

Documents for a Computer Product

Critical Documents

Objectives: defines need to be met and goals, constraints, and priorities
Specifications: defines what the product must do to meet objectives
Schedule
Budget: existance forces technical decisions that would be avoided otherwise
Organization Chart
Space allocations
Estimate, forcast, prices

Documents for a university department

Objectives
Course Descriptions
Degree requirements
Research proposals
Class Schedule and teaching assignments
Budget
Space allocation
Assignment of staff and graduate students

Documents for a Software Project

Objectives
Product Specifications
Schedule
Budget
Space allocation
Organization chart

Why have formal documents

writing decisions down
documents communicate decisions
documents provide database and checklist for management
A written plan is precise and communicable

Chapter 11: Plan to Throw One Away

Use a pilot project and throw it away to learn about the problem and solution space.

The only constancy is change itself

As projects progress, actual need and perception of need change.

Plan the system for change

Use:

modular design
subroutines
definition of intermodule interfaces
documentation
high-level language
self-documenting techniques
numbered versions

Plan the organization for change

plans as tentative:

plans
milestones
schedules

Keep 2-3 developers unassigned to specific tasks to handle unexpected changes.

Reassignment from technical to managerial should be “reassignment”.

Surgical Type programming teams helps solve management problems of change..

Two steps forward, one step back

Changes after delivery are “program maintenance”

repair design defects
maintenance costs ~40% more

Fixing a defect has 20-50% chance of introducing another defect.

regression testing is essential, but costly

One step forward, one step back

Repairs

destroy structure
increase entropy
increase disorder
less focus on fixing design flaws
more focus on fixing bugs introduced by fixes

Systems building: entropy-decreasing process

Program Maintenance: entropy-increasing process

Chapter 12: Sharp Tools

individualized tools hamper communication
tool lifetime: technology changes when machine or working environment changes
more efficient: common development and maintenance tools

Manager needs to set aside time and resources for tool building and maintenance.

What tools?

computer facility
operating system
language
utilities
debugging aids
test-case generators
text-processing system

Target Machines

Target Machine: machine for which program is written Vehicle Machine: machine on which program is developed

Target Facility: target machines + operators and system programmer

The book mentions some target specs that are likely outdated now.

Debugging machine: vehicle machine + debugging aids

Vehicle Machines and Data Services

Simulators: vehicle machine simulates target machine that’s dependable but not necessarily accurate Compiler and assembler: compile code for the target system Programming library and accounts:

group/programmer had area where copies of code is kept
when ready, copy passed to manager for integration
only manager could make changes Programming Tools: Toolsmith builds and maintains programming tools Documentation System: saves the most labor
Too much documentation: provide a map to work through important docs or work to reduce bulk
Too little documentation: is a problem Performance Simulator: required

High-Level Language and Interactive Programming

Most important tools:

High-level language
Interactive programming system

High-level language

Pros:

improves productivity
debugging speed Cons:
not flexible enough
too big
too slow

Interactive Programming