Brooks's Law
debt(d9/e5/b5/t5)
Closest to 'silent in production until users hit it' (d9). The detection_hints explicitly state 'automated: no' and the code_pattern describes symptoms like sprint velocity decreasing — these are only observable retrospectively through project metrics or post-mortem review, never caught by any tool.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix indicates the remedy isn't a line change but a management/structural decision: deferring hires, restructuring workstreams, or reducing scope — this touches team composition, project planning, and stakeholder communication across the organisation, but stops short of full architectural rework.
Closest to 'persistent productivity tax' (b5). Applies_to includes web and cli broadly, and the common_mistakes show the misapplication (adding developers to a late project) creates lasting drag: onboarding overhead, communication explosion, and coordination costs slow multiple work streams for weeks or months. It doesn't reshape the entire system architecture (b7+) but it does impose a persistent tax on delivery.
Closest to 'notable trap — a documented gotcha most devs eventually learn' (t5). The misconception field explicitly states the trap: people overgeneralise and think Brooks's Law means 'never add developers,' when it specifically applies to already-late projects. This is a well-documented management gotcha that most practitioners learn after experiencing it, not an instantly obvious or catastrophic misreading.
Also Known As
TL;DR
Explanation
Fred Brooks observed in 'The Mythical Man-Month' (1975) that software tasks cannot be divided arbitrarily among workers. New team members require training, reducing the productivity of existing members. They also increase communication channels — a team of n has n(n-1)/2 communication paths, growing quadratically. The short-term hit to productivity from adding people to a late project almost always delays it further. The correct response to lateness is usually scope reduction.
Common Misconception
Why It Matters
Common Mistakes
- Adding developers to a late project under pressure — training overhead plus communication explosion delays the project further.
- Underestimating onboarding time — a new developer is not productive for weeks or months on a complex codebase.
- Not reducing scope when behind schedule — the only options are: reduce scope, extend timeline, or ship late.
- Treating software development as linearly scalable — 9 women cannot make a baby in 1 month.
Code Examples
// Manager's instinct — adds 3 developers to a late project:
// Project 3 weeks behind deadline
// Add 3 new developers
// Senior devs spend 2 weeks onboarding them
// Communication meetings increase from 10/week to 30/week
// Project ships 5 weeks late instead of 3
// -- Brooks's Law in action --// Correct response to lateness — reduce scope:
// Project 3 weeks behind deadline
// Options:
// 1. Remove lowest-priority features from current sprint
// 2. Negotiate deadline extension with stakeholders
// 3. Ship current progress and defer remaining features
// All three ship faster than adding developers