---
title: "Why software development is complex; man-month myth"
subject: "Software Engineering"
chapter: 1
key: "semester_5/software_engineering:complex-development"
source: https://www.bctengineer.com/q/semester_5/software_engineering/complex-development
site: BCT Engineering
---

# Why software development is complex; man-month myth

Software Engineering · Chapter 1: Software Process and requirements

- Asked in: year not given, 7 marks
- Video: [Mythical Man Month: Why More Manpower Doesn’t Mean Faster Work](https://www.youtube.com/watch?v=Xsd7rJMmZHg) — iluli by Mike Lamb
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/complex-development
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1

## Question

What makes software development process complex? The simple man-month measurement and additional workers assignment for delayed project does not work in software project, why?

## Short answer

Software development is complex due to essential difficulties: complexity, conformity, changeability, and invisibility. The man-month measure fails because tasks are not partitionable, new members require training, and communication overhead grows quadratically. Adding people to a late project often makes it later (Brooks's law).

## Answer

#### Why software development is complex
Software development is complex mainly because of the nature of software itself. Fred Brooks ("No Silver Bullet") gives four **essential difficulties**:

1. **Complexity**: a program has a huge number of states and interacting parts, and no two parts are alike. Complexity grows faster than size, making it hard to understand, test and communicate.
2. **Conformity**: software must conform to many external interfaces, laws, business rules and existing systems, which are often arbitrary and change over time.
3. **Changeability**: because software is easy to change, it is constantly asked to change (new features, new hardware, new rules).
4. **Invisibility**: software is intangible and cannot be drawn in one simple geometric picture, so progress and design are hard to see.

Other practical reasons:
- Requirements are unclear and keep changing; users and developers speak different "languages".
- Many people must communicate and coordinate.
- Estimating effort is difficult; productivity varies a lot between people.
- Fast-changing technology and tools.
- Testing can show the presence of bugs but cannot prove their absence.

#### Why the man-month measure and adding people to a late project do not work
The **man-month (person-month)** treats effort as if people and months were interchangeable: 12 person-months = 4 people for 3 months = 12 people for 1 month. Brooks showed this is a myth, and stated **Brooks's law**: *"Adding manpower to a late software project makes it later."*

Reasons:
1. **Tasks cannot be perfectly divided.** People and months are interchangeable only when a task can be split among workers with no communication (like picking cotton). Many software tasks have sequential constraints: design must come before code, and some modules depend on others. "Nine women cannot make a baby in one month."
2. **Training (ramp-up) time.** New people must learn the project, design, code and tools. Experienced members must stop their own work to train them, so productivity drops at first.
3. **Communication overhead.** With *n* people, the number of communication paths is n(n − 1)/2.
   - 4 people: 4 × 3 / 2 = **6** paths
   - 8 people: 8 × 7 / 2 = **28** paths
   - 12 people: 12 × 11 / 2 = **66** paths

   Doubling the team more than quadruples communication, so time spent in meetings and coordination grows faster than the work output.
4. **Repartitioning work.** The remaining work must be re-divided and re-planned, which itself takes time and causes errors.
5. **Integration and testing** effort increases as more people produce more interfaces.

Example: a project is planned as 12 person-months, with 4 people working for 3 months. At the end of month 2 it is one month behind schedule (only 4 of the 8 planned person-months are done). Adding 4 more people means 1–2 weeks of training by existing staff, communication paths rising from 6 to 28, and re-dividing the modules. The project is likely to finish even later than if the original team had continued.

Therefore effort cannot be measured and scheduled simply in man-months; schedules must account for communication, training and task dependencies, and late projects are better rescued by reducing scope or re-planning than by adding staff.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. Which set lists Brooks's four essential difficulties of software?
   A. Cost, time, quality, scope
   B. Speed, memory, storage, network
   C. Analysis, design, coding, testing
   D. Complexity, conformity, changeability, invisibility
   Answer: D. Brooks's 'No Silver Bullet' lists complexity, conformity, changeability and invisibility. (Key point: Brooks's essential difficulties)

2. What does Brooks's law state?
   A. Adding manpower to a late software project makes it later
   B. Adding programmers always speeds up a project
   C. Software cost is proportional to team size
   D. Late projects should double their testing time
   Answer: A. New people need training and add communication overhead, so a late project gets later. (Key point: Brooks's law)

3. Why is the man-month measure misleading for software?
   A. Months are always more valuable than people
   B. Software has no effort
   C. People and months are interchangeable only if tasks can be split with no communication, but software tasks have sequential dependencies
   D. It overestimates for tiny teams only
   Answer: C. Tasks cannot be perfectly divided; 'nine women cannot make a baby in one month'. (Key point: Man-month myth)

4. How many communication paths exist among 8 people using n(n-1)/2?
   A. 16
   B. 28
   C. 56
   D. 64
   Answer: B. 8 x 7 / 2 = 28 paths. (Key point: Communication paths)

## Related in Software Engineering

- [Current process models; why waterfall is not accurate](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Awaterfall-not-accurate) — Software Engineering, chapter 1
- [Why unit tests are not enough](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aunit-test-not-enough) — Software Engineering, chapter 8
- [Requirement management process](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-management) — Software Engineering, chapter 1
- [Book store process model](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Abook-store-process-model) — Software Engineering, chapter 2
- [CMM key process areas and continuous improvement](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Acmm-continuous-improvement) — Software Engineering, chapter 9
- [Versioning process and its components](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aversioning-process) — Software Engineering, chapter 10

## Related in other subjects

- [Embedded software development process](https://www.bctengineer.com/question.md?key=semester_6%2Fembedded_system%3Asoftware-development-flow) — Embedded System, chapter 3, asked 3×
- [Operating environment makes projects complex, uncertain](https://www.bctengineer.com/question.md?key=semester_7%2Fproject_engineering%3Atask-environment-complex-uncertain-nepal) — Project Engineering, chapter 1
- [Software process models and effort estimation](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-process-models) — Instrumentation II, chapter 9, asked 2×
- [Spiral model of software development](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Aspiral-model) — Instrumentation II, chapter 9, asked 3×