EFFORT and DURATION are DIFFERENT QUANTITIES, and confusing them is the root error in software scheduling. EFFORT person-months — total work to be done DURATION calendar months — elapsed time STAFF people = effort / duration THE NAIVE ASSUMPTION: effort and duration are freely interchangeable, so 24 person-months can be 24 people for one month, or 1 person for 24 months, or anything between. THIS IS FALSE IN BOTH DIRECTIONS, and the reasons differ. THE ORGANISATION OF SOFTWARE PROJECTS is such that the relationship is constrained by: · SEQUENTIAL DEPENDENCIES — some work cannot start until other work finishes, no matter how many people wait · COMMUNICATION OVERHEAD — n people have n(n−1)/2 communication paths · TRAINING / RAMP-UP — a new person consumes the time of an experienced one before contributing · TASK PARTITIONABILITY — you cannot split every task COCOMO's duration formula encodes this empirically: D = c × E^d with d ≈ 0.32 to 0.38 Because d is well BELOW 1, duration grows much more slowly than effort. The model is asserting that a project's calendar time is largely determined by its size and mode, and is NOT a free variable you can trade against staff. WORKED — semi-detached, from the previous topic's constants: 50 KLOC: E = 239.87 pm, D = 17.02 mo, N = 14.09 people 100 KLOC: E = 521.34 pm, D = 22.33 mo, N = 23.34 people EFFORT more than doubled (2.17×). DURATION rose only 31% (1.31×). STAFF rose 66% (1.66×). → the model absorbs extra work mostly through headcount, but it does NOT let you hold duration constant while doing so.

BROOKS'S LAW: "Adding manpower to a late software project makes it later." THE THREE MECHANISMS behind it: 1. RAMP-UP TIME. A new team member is unproductive at first and CONSUMES the time of existing members for training. The people teaching are the people you needed coding. 2. COMMUNICATION OVERHEAD. Paths grow as n(n−1)/2: 4 people → 6 paths 8 people → 28 16 people → 120 32 people → 496 Every path is a potential misunderstanding and a real coordination cost. 3. LIMITED TASK DIVISIBILITY. Brooks's own image: a task that one person does in 10 months cannot be done by 10 people in one month if the work is sequential — "the bearing of a child takes nine months, no matter how many women are assigned." A QUANTIFIED MODEL. Let each person contribute productivity 1, and let each communication path cost a fraction k of one person's output: effective output W(n) = n − k × n(n−1)/2 With k = 0.02 (each pair costing 2% of one person): n = 1 W = 1.00 n = 4 W = 4 − 0.02×6 = 3.88 n = 8 W = 8 − 0.02×28 = 7.44 n = 12 W = 12 − 0.02×66 = 10.68 n = 16 W = 16 − 0.02×120 = 13.60 n = 20 W = 20 − 0.02×190 = 16.20 n = 26 W = 26 − 0.02×325 = 19.50 n = 30 W = 30 − 0.02×435 = 21.30 n = 40 W = 40 − 0.02×780 = 24.40 n = 51 W = 51 − 0.02×1275 = 25.50 ← MAXIMUM n = 60 W = 60 − 0.02×1770 = 24.60 n = 80 W = 80 − 0.02×3160 = 16.80 n = 101 W = 101 − 0.02×5050 = 0.00 ← ZERO OUTPUT THE CURVE PEAKS AND THEN FALLS. Beyond about 51 people (at this k) adding staff REDUCES output, and at 101 people the team produces nothing at all — everyone is fully occupied communicating. The peak is at n ≈ 1/k + 0.5, so the model says plainly: THE MORE EXPENSIVE COMMUNICATION IS, THE SMALLER THE OPTIMAL TEAM. At k = 0.05 (poorly documented, distributed, unfamiliar codebase) the peak is around 20 people; at k = 0.01 (well-modularised, good interfaces, clear ownership) it is around 100. THAT IS THE ACTIONABLE INSIGHT, and it connects straight back to the design unit: LOW COUPLING REDUCES k. Good modular design does not merely make code pleasant — it raises the number of people who can usefully work on the system at once. Architecture is a staffing decision. RAMP-UP, WORKED — the late-project case: A project is 3 months from its deadline with 200 person-months of work left and 20 people, so it needs 200/20 = 10 months. Management adds 10 people. Each new person needs 1 month of a mentor's time, and produces nothing in month 1, then 60% output in month 2, then full. cost of training = 10 mentor-months, lost from the existing team new output over 3 months = 10 × (0 + 0.6 + 1.0) = 16 person-months existing output over 3 months = 20 × 3 − 10 = 50 total = 66 person-months WITHOUT the addition: 20 × 3 = 60 person-months. So the addition gained 6 person-months against 200 needed — and that is BEFORE counting the extra communication overhead, which for 30 people versus 20 is 0.02 × (435 − 190) = 4.9 person-months lost. NET GAIN ≈ 1.1 person-months. Essentially nothing, from a 50% increase in headcount. THE CORRECT RESPONSES to a late project, in order of value: 1. REDUCE SCOPE — cut features, ship the core. The only lever that reliably works. 2. EXTEND THE DEADLINE, if it is negotiable. 3. REMOVE IMPEDIMENTS — unblock what is blocked, remove non-essential work from the team. 4. ADD PEOPLE, and only to work that is genuinely separable and only if the deadline is far enough away for ramp-up to pay back. THE ORDER MATTERS. Adding people is last because it is the slowest-acting and most often counterproductive. BROOKS'S SURGEON TEAM (the "chief programmer team") is his proposed response: rather than many peers, one strong designer supported by specialists — a copilot, an administrator, a toolsmith, a tester, a language lawyer — so the communication paths run through one mind rather than a mesh.

STAFFING IS NOT CONSTANT over a project. The RAYLEIGH CURVE (Putnam) describes the observed shape: staff ramps up, peaks around the middle-to-late analysis and coding phase, and tails off through testing. staff │ ╭──╮ │ ╭─╯ ╰─╮ │ ╭─╯ ╰──╮ │ ╭─╯ ╰────╮ └────────────────────────── start end PLANNING FOR AVERAGE STAFF IS THEREFORE WRONG: COCOMO's N = E/D is an AVERAGE, and the peak is typically about 1.3 to 1.5 times it. A project computed to need 14 people will need around 20 at its peak, and fewer at both ends. Hiring 14 and holding them flat wastes them early and starves the project at its peak. PUTNAM'S SOFTWARE EQUATION — the other classic model, and it makes the schedule-compression penalty explicit: Size = C × K^(1/3) × T^(4/3) where K is total effort (person-years), T is duration (years), C is a technology constant. Rearranged for effort: K = Size³ / (C³ × T⁴) READ THE EXPONENT ON T: effort is inversely proportional to the FOURTH POWER of duration. Compressing a schedule is therefore brutally expensive: cut duration to 90% → effort × 1/0.9⁴ = 1.52× cut duration to 80% → effort × 1/0.8⁴ = 2.44× cut duration to 75% → effort × 1/0.75⁴ = 3.16× cut duration to 50% → effort × 1/0.5⁴ = 16× A 25% schedule cut costs roughly THREE TIMES the effort. This is why experienced managers treat schedule compression requests as scope conversations. THE IMPOSSIBLE REGION: both COCOMO and Putnam imply a minimum duration below which a project cannot be completed at any cost, commonly quoted at about 75% of the nominal schedule. Beyond that, adding effort does not help — the sequential dependencies and communication overhead dominate entirely. SCHEDULING TECHNIQUES — how the estimate becomes a plan: WORK BREAKDOWN STRUCTURE (WBS) decompose deliverables into tasks small enough to estimate (a common guideline: no task longer than 2 weeks) ACTIVITY NETWORK / PERT tasks as nodes with dependencies; identifies the CRITICAL PATH — the longest dependent chain, which sets the minimum duration GANTT CHART / BAR CHART tasks against a calendar, showing staff allocation and slack MILESTONES AND DELIVERABLES a milestone is an end-point of a process activity; a deliverable is a project result delivered to the customer THE CRITICAL PATH IS THE KEY CONCEPT: only tasks on the critical path affect the end date. Adding people to a non-critical task changes nothing about delivery, which is another reason naive staffing increases fail — the extra people are frequently put where they cannot help. AND THE STANDARD ADVICE, from Sommerville: estimating is difficult, so add CONTINGENCY. A common rule is to estimate as if nothing will go wrong, then increase the estimate to cover anticipated problems, and add a further contingency for unanticipated ones — often quoted as roughly 30% for anticipated and 20% more for unanticipated problems.