Brooks' Law
Adding manpower to a late software project makes it later.
Brooks' Law was articulated by Frederick P. Brooks Jr. in The Mythical Man-Month: Essays on Software Engineering (1975), based on Brooks's experience as project manager for IBM's OS/360 operating system. The law's mechanism is twofold: ramp-up time (newly added engineers must learn the system before they contribute productively, and the engineers needed to onboard them are pulled from productive work to do so) and communication overhead (the number of communication channels in a team grows as n(n-1)/2, so doubling team size more than doubles coordination cost). The 1995 anniversary edition of The Mythical Man-Month added 'No Silver Bullet' and other essays, with Brooks reflecting on which propositions had held up and which had not. Brooks' Law is widely cited in software engineering and has substantial empirical and intuitive support — the conversation between adding-people and shipping-faster is one every software leader recognizes — though the law has been critiqued for being asserted as if absolute when its actual force varies by team modularity, project structure, and onboarding investment.
Core components
- Adding manpower to a late project makes it later
- Ramp-up time for new engineers
- Communication overhead grows as n(n-1)/2
- Contrast with intuitive 'throw more people at it' management response
- Implication: software development time cannot be linearly traded for headcount
- Connection to project planning and the cost of late-cycle additions
Primary use case
Software project management and planning; pushback on intuitive but counterproductive 'add more engineers' responses to schedule pressure; teaching framework in software engineering; reference in agile project management; foundational consideration in team scaling decisions.
Common criticisms
- Asserted as if absolute when its strength varies by team modularity, project structure, and onboarding investment — well-modularized projects with strong onboarding can absorb new engineers with less productivity penalty
- doesn't quantify when adding people becomes net-negative vs net-positive
- doesn't address adding entire pre-formed teams to parallel work streams (which can succeed where adding individuals to one team fails)
- empirical evidence is largely from large monolithic projects of the 1960s-80s, with less direct evidence for modern microservices or platform engineering contexts
- can be invoked as excuse against any team growth even when justified
- frames software development as fundamentally constrained by communication when modern tooling has substantially changed coordination economics.
Lineage
- Siblings
- No Silver Bullet, Conway's Law