--- license: Apache-2.0 name: mythical-man-month description: Classic software engineering text on project management, Brooks's Law, and the nature of software complexity category: Research & Academic tags: - software-engineering - project-management - brooks-law - complexity - classic --- # SKILL: The Mythical Man-Month Strategic framework for managing complex system development, revealing why intuitive approaches to scaling, coordination, and change management systematically fail. ## DECISION POINTS ### Scope Change Response Matrix | Change Size | Timeline Pressure | Action | |-------------|------------------|---------| | <10% features | Low pressure | Accept change, adjust internally | | <10% features | High pressure | Accept change, extend deadline 1-2 weeks | | 10-25% features | Low pressure | Formal re-estimation, likely extend timeline | | 10-25% features | High pressure | **Cut other features OR extend deadline** | | >25% features | Any pressure | **Stop and redesign architecture** | | >50% features | Any pressure | **Treat as new project, plan to throw one away** | ### Team Scaling Decision Tree ``` IF task has zero interdependencies THEN people scale linearly (rare in software) IF task requires coordination between workers ├─ IF coordination is <20% of effort per person │ THEN add people cautiously (2-3x max team size) ├─ IF coordination is 20-50% of effort │ THEN keep team small (3-7 people max) └─ IF coordination is >50% of effort THEN redesign task to reduce dependencies IF project is late AND <50% complete THEN extend deadline OR cut scope (never add people) IF project is late AND >50% complete THEN extend deadline only (adding people guarantees failure) ``` ### Agent Architecture Coordination Strategy ``` IF agents need shared state ├─ IF state changes <10 times/minute │ THEN use single coordinator with state ownership └─ IF state changes >10 times/minute THEN redesign to eliminate shared state IF agents need to negotiate outcomes ├─ IF <3 agents total │ THEN allow peer-to-peer communication └─ IF ≥3 agents THEN use mediator pattern (single orchestrator) IF task requires conceptual unity THEN single orchestrator with specialized tools NOT peer-to-peer agent democracy ``` ### Documentation Priority Decisions ``` IF you can't write clear spec in 2 pages THEN design isn't ready for implementation IF writing documentation feels painful THEN you haven't decided what you're building IF spec and code diverge ├─ IF spec is more accurate → fix code ├─ IF code is more accurate → update spec └─ IF both are wrong → stop and redesign Priority order: 1. User interface/API spec (what system does) 2. Architecture overview (how pieces fit) 3. Individual component specs 4. Implementation details (last) ``` ## FAILURE MODES ### The Late Project Death Spiral **Symptoms**: Project behind schedule, management proposes adding people, velocity decreases further **Detection**: "We're 3 months late, let's hire 5 more developers" **Root Cause**: Training overhead + repartitioning costs exceed productivity gains **Fix**: Accept delay OR cut scope OR redesign for different partitioning. Never add people to late project in final stages. ### Committee Architecture Syndrome **Symptoms**: System has multiple interaction paradigms, inconsistent interfaces, users can't form mental model **Detection**: Every feature requires learning new interaction pattern **Root Cause**: Democratic design process without single architectural vision **Fix**: Designate single architect for external interfaces. Implementation can be distributed, architecture must be unified. ### The 90% Done Trap **Symptoms**: Progress reports show 90% complete for months, testing keeps finding integration issues **Detection**: No concrete deliverable milestones, "almost done" status persists >2 weeks **Root Cause**: Underestimated integration complexity, no sharp completion criteria **Fix**: Define binary milestones (passes all tests, user can complete workflow X). Allocate 50% of schedule to integration/testing. ### Requirements Stability Delusion **Symptoms**: Every change request treated as scope creep emergency, architecture can't accommodate variations **Detection**: "But that's not what we originally agreed to!" repeated frequently **Root Cause**: Assuming requirements won't change vs. designing for inevitable change **Fix**: Plan for 25% requirement changes. Build clean interfaces. Treat change as normal, not exceptional. ### Second System Effect **Symptoms**: Reimplementation includes every withheld feature plus kitchen sink, loses original system's elegance **Detection**: New version has 3x features but takes 5x longer to learn **Root Cause**: Architect compensating for first system's limitations by including everything **Fix**: Maintain discipline. Second system should be refined, not inflated. Test conceptual integrity with naive users. ## WORKED EXAMPLES ### Multi-Agent Code Review System **Scenario**: Building automated code review with 4 specialized agents (syntax, security, performance, architecture). **Naive Approach**: Peer-to-peer agent communication where each agent reviews independently then they negotiate final score. **Brooks Analysis Applied**: 1. **Communication overhead**: 4 agents = 6 communication links. Each agent must understand others' reasoning. 2. **Conceptual integrity**: Who owns the final "accept/reject" decision? Committee vote creates inconsistent standards. 3. **Change impact**: New review criteria requires updating all 4 agents' negotiation logic. **Expert Decision Process**: - **Architecture choice**: Single orchestrator agent with 4 specialized tool agents - **Reasoning**: Orchestrator maintains consistent review philosophy, tools provide analysis - **Interface design**: Each tool returns structured data + confidence score, orchestrator decides - **Change management**: New criteria only requires updating orchestrator logic **What novice misses**: Tries to make agents "smart" and autonomous **What expert catches**: Minimizes coordination points, preserves decision consistency **Result**: 5x simpler debugging, consistent review standards, easy to modify review criteria ### Late AI Training Pipeline Project **Situation**: ML training pipeline 2 months behind, manager wants to add 3 GPU engineers. **Decision Process**: 1. **Task analysis**: Pipeline requires sequential stages (data → preprocessing → training → validation) 2. **Current bottleneck**: Data preprocessing taking 3x expected time 3. **Communication overhead**: New engineers need 2-4 weeks to understand custom data formats 4. **Training burden**: Existing 2 engineers must stop work to onboard newcomers **Brooks-informed decision**: - **Don't add people**: Training cost (8 person-weeks) exceeds remaining schedule slack (6 weeks) - **Cut scope instead**: Defer advanced preprocessing features, use simpler baseline - **Extend deadline**: 4 weeks for current team to finish vs. 8+ weeks with added people **Outcome**: Delivered in 10 weeks vs. estimated 12+ weeks if people added ## QUALITY GATES ### Design Phase Completion - [ ] Single architect can explain system in 2-page overview - [ ] External interfaces documented before any implementation starts - [ ] User mental model tested with 3+ naive users - [ ] All major components identified with <5 interfaces between them - [ ] Change scenarios (25% requirement shift) don't break architecture ### Development Phase Milestones - [ ] Each milestone produces working system (not just components) - [ ] Integration budget allocated (25% of total effort minimum) - [ ] Communication overhead measured: coordination time <20% per developer - [ ] Team size stable: no additions after 50% schedule point - [ ] Documentation current: spec changes drive code changes, not reverse ### Pre-Ship Quality Gates - [ ] Conceptual integrity verified: naive user can predict system behavior - [ ] All planned features implemented OR explicitly descoped with stakeholder sign-off - [ ] System testing complete: full end-to-end workflows pass - [ ] Performance meets requirements under realistic load - [ ] Documentation sufficient for maintenance team handoff ## NOT-FOR BOUNDARIES **This skill should NOT be used for**: - Perfectly partitionable tasks (data processing, batch jobs) → Use parallel processing patterns - Research/exploration projects → Use rapid prototyping methodologies - Small teams (<4 people) → Coordination overhead is minimal, other factors dominate - Well-understood problems with stable requirements → Use standard SDLC approaches - Real-time systems with hard latency constraints → Use real-time engineering principles **Delegate instead**: - For technical architecture decisions → Use `system-design` skill - For individual productivity → Use `deep-work` and `focus-management` skills - For requirements gathering → Use `stakeholder-management` skill - For team dynamics → Use `team-leadership` skills - For project tracking → Use `agile-project-management` skill **Key boundary**: Brooks's insights apply when **coordination overhead** becomes significant factor. If your team spends <10% time on coordination, other management approaches may be more relevant.