The Mythical Man-Month¶
Brooks, F. P., & Jr. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
Cited by¶
12 citations across 12 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Branching and Merging
- Instead of every contributor synchronizing with every other contributor on every change — an O(n²) communication burden that grows prohibitive — each line proceeds in isolation and all interaction-cost is deferred to a bounded, schedulable merge step.
This sourceEstablishes that the number of pairwise communication paths among n contributors grows combinatorially as n(n−1)/2, so coordination overhead rises roughly as the square of team size while output grows only linearly — the basis for the claim that continuous all-to-all coordination is an O(n^2) burden.
- Instead of every contributor synchronizing with every other contributor on every change — an O(n²) communication burden that grows prohibitive — each line proceeds in isolation and all interaction-cost is deferred to a bounded, schedulable merge step.
- Decomposition
- Diseconomies of Scale
- Software engineering (non-obvious): Brooks's law—adding people to a late software project makes it later—because the onboarding burden and the combinatorial growth of communication paths outpace the marginal labor added.
This sourceOrigin of Brooks's law ("adding manpower to a late software project makes it later"): onboarding (ramp-up) cost and the combinatorial growth of communication paths overtake the marginal labor added, so past a project-specific size the next engineer delays rather than accelerates delivery.
- Software engineering (non-obvious): Brooks's law—adding people to a late software project makes it later—because the onboarding burden and the combinatorial growth of communication paths outpace the marginal labor added.
- Hierarchy
- Brooks's Mythical Man-Month
This sourceOrigin of Brooks's law ("adding manpower to a late software project makes it later"): onboarding (ramp-up) cost and the combinatorial growth of communication paths overtake the marginal labor added, so past a project-specific size the next engineer delays rather than accelerates delivery.
- Brooks's Mythical Man-Month
- Objective Creep
- In software projects, a scope sized for one feature accumulates "while we're in there" additions, and the original feature ships late, diluted, or not at all — the familiar scope creep.
This sourceClassic account of scope growth and schedule dilution in software projects, including the accretion of features under execution.
- In software projects, a scope sized for one feature accumulates "while we're in there" additions, and the original feature ships late, diluted, or not at all — the familiar scope creep.
- Progressive Refinement from Core Model
- When they do (fine-tuning from a pre-trained model, successive overrelaxation around a linear solution), the pattern applies; when they don't (random-init gradient descent), it doesn't.
This sourceOrigin of Brooks's law ("adding manpower to a late software project makes it later"): onboarding (ramp-up) cost and the combinatorial growth of communication paths overtake the marginal labor added, so past a project-specific size the next engineer delays rather than accelerates delivery.
- When they do (fine-tuning from a pre-trained model, successive overrelaxation around a linear solution), the pattern applies; when they don't (random-init gradient descent), it doesn't.
- Scope Creep
- In software and product development, features are added one at a time, each cheap against the current release, until the project ships late or never — the familiar feature creep and gold-plating.
This sourceNames feature accretion and the second-system effect in software projects and analyzes how successor systems accumulate features beyond their charter.
- In software and product development, features are added one at a time, each cheap against the current release, until the project ships late or never — the familiar feature creep and gold-plating.
- Second-System Effect
- In software architecture, it is the original case: a successor operating system carrying every feature postponed from earlier ones and collapsing under its own ambition.
This sourceChapter 5 coins the 'second-system effect': the most dangerous system a designer builds is the second, into which all the frills and ideas deferred from a constrained first system are poured, producing overengineering (the OS/360 case).
- In software architecture, it is the original case: a successor operating system carrying every feature postponed from earlier ones and collapsing under its own ambition.
Domain-specific¶
- Meeting Inflation
- Coordination requirements in a team grow with the square of the number of interdependent people — Brooks's n(n−1)/2 pairwise channels among n interdependent workers, so each further person joining adds n new coordination links rather than one
This sourceBrooks's chapter 2, which states the quadratic the sentence rests on — 'if each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2' — in the number of interdependent workers, and adds that this communication effort 'quickly dominates the decrease in individual task time brought about by partitioning'. Carries the closing proposition: because intercommunication effort rises as n(n-1)/2 and 'quickly dominates the decrease in individual task time brought about by partitioning', 'adding more men then lengthens, not shortens, the schedule'; the agile ceremony list and the fragmentation of deep-work blocks are not in Brooks.
- Coordination requirements in a team grow with the square of the number of interdependent people — Brooks's n(n−1)/2 pairwise channels among n interdependent workers, so each further person joining adds n new coordination links rather than one
- Progress Illusion
- The project then glides comfortably toward its deadline accumulating activity until a milestone forces an outcome measurement and the gap is exposed — the artifact count high, the sprint board full, the team exhausted, and the actual target metric unchanged
This sourceBrooks's chapter 14, 'Hatching a Catastrophe', carries the glide-then-collision structure this sentence rests on — slippage accrues 'one day at a time' and stays invisible until a milestone 'defined with knife-edge sharpness' forces a real measurement; the sprint-board furniture and the activity-as-outcome-proxy reading are the article's own.
- The project then glides comfortably toward its deadline accumulating activity until a milestone forces an outcome measurement and the gap is exposed — the artifact count high, the sprint board full, the team exhausted, and the actual target metric unchanged
Mechanisms¶
- Channel Consolidation
- Handoff Path Pruning
- Its failure mode is the Brooks's-Law hazard read in reverse: the same combinatorial communication overhead that pruning reduces also hides which edges were load-bearing, so a real safety hop can be cut and its value discovered only when the errors it silently caught begin to escape.
This sourcePruning handoffs cuts edges in exactly that graph, which is also why removing a load-bearing edge is so easy to underestimate.
- Its failure mode is the Brooks's-Law hazard read in reverse: the same combinatorial communication overhead that pruning reduces also hides which edges were load-bearing, so a real safety hop can be cut and its value discovered only when the errors it silently caught begin to escape.
Verification¶
This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 2 other ways.
- https://www.oreilly.com/library/view/the-mythical-man-month/0201835959/ ×2
- https://www.pearson.com/en-us/subject-catalog/p/mythical-man-month-the-essays-on-software-engineering/P200000000259 ×1
Registry ID ref:4f437d8070c2 · see in the full table