The Mythical Man-Month¶
Brooks Jr, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
Cited by¶
23 citations across 23 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.
SupportedVerified against the source
- 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.
Supported in partVerified against the source
- 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
- Communication Channel Redesign
- Its honest failure mode is that adding channels adds coordination overhead: communication cost grows roughly with the number of pairwise paths, the intuition behind Brooks's Law, so more connectivity can slow a group instead of speeding it.
This sourceExplains that pairwise communication overhead grows as participants are added, the mechanism underlying Brooks's Law that more connectivity can slow work.
- Its honest failure mode is that adding channels adds coordination overhead: communication cost grows roughly with the number of pairwise paths, the intuition behind Brooks's Law, so more connectivity can slow a group instead of speeding it.
- Coordination Cost Accounting
- Its strength is converting "we're drowning in coordination" into a number attached to a specific seam, and exposing the trap where adding a specialist adds more coordination than it saves — the phenomenon behind Brooks's Law,
This sourceExplains that adding people to a late project can increase training and intercommunication overhead, with pairwise communication interfaces growing as n(n−1)/2.
- Its strength is converting "we're drowning in coordination" into a number attached to a specific seam, and exposing the trap where adding a specialist adds more coordination than it saves — the phenomenon behind Brooks's Law,
- Coordination Cost Modeling
- Its strength is exposing the super-linear cost that linear headcount reasoning hides — the reason Brooks's Law warns that adding people to a late project can make it later, as the new communication paths cost more than the added hands produce.
This sourceAdding staff to a late software project can delay it because training, repartitioning, and communication overhead rise with team size.
- Its strength is exposing the super-linear cost that linear headcount reasoning hides — the reason Brooks's Law warns that adding people to a late project can make it later, as the new communication paths cost more than the added hands produce.
- 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 sourceExplains that the number of potential communication channels grows combinatorially as a team grows.
- 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.
- Hiring Pace Limit
- … tested — adding people to an effort that is already straining to absorb them slows it down rather than speeding it up, because the newcomers consume the very mentoring bandwidth that would have carried the work, a dynamic Fred Brooks named for software teams and that applies to any craft transmitted person-to-person.
This sourceArgues that adding people to an effort already straining to absorb them can slow it down further.
- … tested — adding people to an effort that is already straining to absorb them slows it down rather than speeding it up, because the newcomers consume the very mentoring bandwidth that would have carried the work, a dynamic Fred Brooks named for software teams and that applies to any craft transmitted person-to-person.
- Platform Team Bottleneck Test
- The underlying math is Brooks's-Law-shaped: coordination that funnels through one node concentrates the cost of every pairwise interaction into a single throat.
This sourceShows that pairwise intercommunication grows quadratically with team size and can erase the gains from adding workers.
- The underlying math is Brooks's-Law-shaped: coordination that funnels through one node concentrates the cost of every pairwise interaction into a single throat.
- Rapid Configuration Prototype
- Its strength is that it converts an irreversible bet into a reversible experiment — a classic throwaway prototype whose only job is to retire risk and then be discarded.
This sourceRecommends building a pilot system to gain experience and expose defects, then discarding and redesigning it instead of delivering the first build as the finished product.
- Its strength is that it converts an irreversible bet into a reversible experiment — a classic throwaway prototype whose only job is to retire risk and then be discarded.
- Recursive Design Breakdown
- It is the practical expression of preserving conceptual integrity across a decomposed design — the property Fred Brooks argued matters more than any individual clever part
This sourceArgues that conceptual integrity matters more than individually clever but incoherent design features.
- It is the practical expression of preserving conceptual integrity across a decomposed design — the property Fred Brooks argued matters more than any individual clever part
- Scalable Governance Cadence
- Underneath both is the structural fact the cadence exists to manage: the communication paths that must align rise roughly with the square of the people involved, so coordination cost grows far faster than headcount unless most of those paths are deliberately cut.
This sourceShows that pairwise coordination paths grow as n(n-1)/2 when every task part must communicate with every other part.
- Underneath both is the structural fact the cadence exists to manage: the communication paths that must align rise roughly with the square of the people involved, so coordination cost grows far faster than headcount unless most of those paths are deliberately cut.
- Staffing Marginal Output Analysis
- A new hire almost always dips output before lifting it — they consume the time of the people training them before contributing — so a snapshot taken during onboarding will slander a hire that would have paid off; this is the heart of Brooks's law, that adding people to a late project can make it later.
This sourceExplains that adding people initially diverts effort to training and communication, which can make a late software project later.
- A new hire almost always dips output before lifting it — they consume the time of the people training them before contributing — so a snapshot taken during onboarding will slander a hire that would have paid off; this is the heart of Brooks's law, that adding people to a late project can make it later.
- Staffing Relief / Cross-Training
- It misleads when people are thrown at a constraint that isn't people-limited — adding hands to a stage bound by tooling, a queue policy, or bad input yields nothing, and during ramp-up it can make things worse
This sourceExplains how adding personnel to a late software project can delay it further because training and communication consume time.
- It misleads when people are thrown at a constraint that isn't people-limited — adding hands to a stage bound by tooling, a queue policy, or bad input yields nothing, and during ramp-up it can make things worse
- Surge Staffing Roster
- Its failure mode is the ramp: pulled people are not instantly productive at the point, and past some depth the coordination and onboarding overhead can swallow the extra hands entirely — adding manpower can make a late effort later
This sourceExplains that added people require training and increase coordination overhead, so adding manpower to a late software project can make it later.
- Its failure mode is the ramp: pulled people are not instantly productive at the point, and past some depth the coordination and onboarding overhead can swallow the extra hands entirely — adding manpower can make a late effort later
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Read against the text for 2 of 23 citations: 1 supported, 1 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 8 other ways.
- https://books.google.com/books/about/The_Mythical_Man_month.html?id=gWgPAQAAMAAJ ×3
- https://search.worldcat.org/title/780471787 ×3
- https://openlibrary.org/books/OL5044740M/The_mythical_man-month ×2
- https://www.cs.cmu.edu/~15712/papers/mythicalmanmonth00fred.pdf ×2
- https://www.oreilly.com/library/view/the-mythical-man-month/0201835959/ ×2
- https://openlibrary.org/isbn/9780201006506 ×1
- https://search.worldcat.org/title/1209136 ×1
- https://search.worldcat.org/title/mythical-man-month-essays-on-software-engineering/oclc/1208696 ×1
Registry ID ref:4f437d8070c2 · see in the full table