Size, Effort & Schedule
From counting functions to predicting delivery dates — the math that ties it all together.
Previous lessons covered the art of estimation — expert judgment, decomposition, analogy. This lesson covers the science. We finally connect three quantities every project manager cares about:
- Size — how big is the thing we're building?
- Effort — how many person-months will it take?
- Schedule — how many calendar months until it's done?
McConnell dedicates three chapters (18–20) to these relationships because they contain some of the most reliable, empirically validated formulas in all of software engineering. The schedule equation in particular is one of the book's most powerful tools.
Measuring Size with Function Points
Lines of code (LOC) is the most obvious way to measure software size, but it has a serious flaw: the same feature can be 50 lines in Python and 500 in Java. Function Point Analysis (FPA) solves this by measuring what the software does rather than how it's written.
Invented by Allan Albrecht at IBM in 1979, function points count five types of business functionality:
The Five Function Types
| Type | What It Measures | Example |
|---|---|---|
| External Inputs (EI) | Data entering the system | Submit order form, upload CSV |
| External Outputs (EO) | Data leaving the system (with processing) | Monthly report, invoice PDF |
| External Inquiries (EQ) | Simple retrieval — in/out with no processing | Search by ID, status lookup |
| Internal Logical Files (ILF) | Logical data groups maintained by the system | Customer table, product catalog |
| External Interface Files (EIF) | Data groups referenced but maintained elsewhere | External payment API data, 3rd-party auth |
Each function type is weighted by complexity (low, average, or high). The weights come from standardized tables maintained by the International Function Point Users Group (IFPUG). For a simplified count, average weights are commonly used:
| Type | Low | Average | High |
|---|---|---|---|
| External Inputs (EI) | 3 | 4 | 6 |
| External Outputs (EO) | 4 | 5 | 7 |
| External Inquiries (EQ) | 3 | 4 | 6 |
| Internal Logical Files (ILF) | 7 | 10 | 15 |
| External Interface Files (EIF) | 5 | 7 | 10 |
Why are ILFs weighted more heavily than inputs?
Internal Logical Files represent persistent, structured data groups that the system must create, read, update, and delete. They imply schema design, data integrity rules, migration strategies, and ongoing maintenance — all of which drive significant development effort. A single ILF like "Customer" might spawn dozens of inputs, outputs, and queries around it.
What about simplified / quick function point techniques?
McConnell describes several shortcuts for when you don't have time for a full IFPUG count:
- Dutch Method: Count only ILFs and EIFs, then multiply by a constant (typically 35 FP per data group). Very fast for early-stage estimates.
- Backfiring: If you already have LOC from a similar project, divide by the language's LOC-per-FP ratio to get approximate function points.
- NESMA Indicative: Count data files and transaction types at a very coarse level. Accuracy: +/- 25%.
These quick methods sacrifice precision for speed — perfect for Cone-of-Uncertainty stages where high precision isn't warranted anyway.
Interactive: Function Point Counter
Below is a mini requirements document for an online bookstore system. Read the requirements, then count the function types. We'll calculate the function points and convert them to estimated lines of code.
Requirements: "BookShelf" Online Bookstore
- Customers can register an account with name, email, and password.
- Customers can log in and update their profile.
- The system maintains a catalog of books (title, author, ISBN, price, stock).
- Customers can search the catalog by title, author, or ISBN.
- Customers can add books to a shopping cart and place orders.
- The system generates a monthly sales report for admin users.
- The system generates an order confirmation email after purchase.
- The system reads from an external payment gateway API to process transactions.
- The system reads shipping rate data from a third-party logistics API.
- The system maintains an order history for each customer.
- Customers can check order status by order number.
Enter your counts below. Use "average" complexity for all items (the default weights). Hint: read each requirement and decide which function type it belongs to.
| Function Type | Weight | Your Count | Points |
|---|---|---|---|
| External Inputs (EI) | x 4 | 0 | |
| External Outputs (EO) | x 5 | 0 | |
| External Inquiries (EQ) | x 4 | 0 | |
| Internal Logical Files (ILF) | x 10 | 0 | |
| External Interface Files (EIF) | x 7 | 0 | |
| Total Unadjusted Function Points | 0 | ||
Computing Effort from Size
Once you have size in function points (or LOC), you can compute effort — the total person-months needed to build the software. This relationship is not linear. As projects get bigger, they don't just need proportionally more effort — they need disproportionately more.
The standard model takes the form:
Effort = a × Sizeb
Where a is a calibration constant and b (the diseconomy of scale exponent) is typically 1.05 to 1.20.
That exponent b is critical. A value of 1.0 would mean linear scaling. But in reality, b is always greater than 1.0, because larger projects face more communication overhead, more integration complexity, and more coordination cost.
"A project that is 10 times as large as another project requires well over 10 times as much effort." — Steve McConnell
The ISBSG method for effort estimation
The International Software Benchmarking Standards Group (ISBSG) maintains a database of thousands of completed projects. Their method:
- Count function points for your project.
- Look up the productivity rate (hours per FP) for your platform, language, and project type in the ISBSG database.
- Multiply:
Effort = FP x Hours-per-FP.
Typical rates range from 2 hours/FP (very productive teams, modern languages) to 30+ hours/FP (embedded systems, regulated industries). The median across the ISBSG database is roughly 10–15 hours/FP.
Interactive: Effort vs. Size Explorer
Adjust the project size and see how effort and schedule change. Compare how different languages handle the same feature set.
The Basic Schedule Equation
Of all the formulas in McConnell's book, this may be the most important. Derived from decades of industry data (Barry Boehm's COCOMO, Putnam's SLIM, QSM's database), the Basic Schedule Equation is remarkably consistent:
Schedulemonths = 3.0 × StaffMonths1/3
The cube-root relationship between effort and schedule is the most thoroughly validated finding in software engineering economics.
What this means in practice: doubling the effort does not halve the schedule.
If a project needs 8 staff-months of effort, the schedule is
3.0 × 8^(1/3) = 3.0 × 2.0 = 6.0 months. If you somehow doubled
the effort to 16 staff-months, the schedule would be
3.0 × 16^(1/3) = 3.0 × 2.52 = 7.6 months — longer, not
shorter, because you now have a bigger project.
The equation gives the nominal schedule — the schedule you'd hit with normal staffing. You can compress it somewhat by adding people, but there's a hard wall.
The 25% Compression Limit
McConnell presents one of the book's most sobering findings: no project has been shown to successfully compress its nominal schedule by more than 25%, regardless of how many resources are thrown at it. Try to compress beyond that and you will:
- Increase defects dramatically
- Burn out your team
- Ironically extend the schedule due to rework
Why exactly 25%? What's the empirical basis?
The 25% figure comes from multiple independent sources: Boehm's COCOMO II data, Putnam and Myers' analysis, and QSM's database of 10,000+ projects. All converge on the same finding. Beyond ~25% compression, the communication overhead from additional staff exceeds the productivity gained. Some researchers put the theoretical minimum even higher, around 20% compression. McConnell uses 25% as the practical limit because even achieving that requires a highly skilled team with excellent processes.
Interactive: Schedule Equation Calculator
Enter the estimated effort for your project. We'll calculate the nominal schedule, then let you try to compress it. Watch what happens when you push past 25%.
Schedule Compression
Drag the slider to try to compress the schedule. The gauge turns red past 25%.
-- months
-- people
Brooks's Law & The Staffing Trap
Fred Brooks wrote in 1975: "Adding manpower to a late software project makes it later." Nearly fifty years later, this remains one of the most ignored truths in our industry.
Why does adding people hurt? Three compounding effects:
- Ramp-up time: New developers need weeks to months to become productive. During ramp-up, they consume the time of existing team members who must mentor them.
- Communication overhead: The number of communication channels grows as
n(n-1)/2. Double the team from 4 to 8 and communication paths jump from 6 to 28. - Task partitioning limits: Not all work is parallelizable. Some tasks depend on others. Nine women can't make a baby in one month.
When can you add people successfully?
Adding people can work under specific conditions:
- Added early in the project (before the halfway point)
- The work is highly partitionable (e.g., independent modules, separate microservices)
- The new people are already familiar with the codebase or technology
- You accept a modest compression (under 25%)
McConnell notes that the worst time to add people is after the 2/3 mark of the schedule. By that point, ramp-up costs and communication overhead virtually guarantee the project will be delayed further.
Interactive: Brooks's Law Simulator
You're managing a project that's running behind schedule. The project is 100 units of work, originally planned for 5 developers over 20 weeks. Each developer completes 1 unit per week.
It's now week 8 and you're already behind. Should you add more developers? Try it and see what happens.
Communication Channels Grow Quadratically
The number of communication channels in a team of n people is
n(n-1)/2. Here's what that looks like in practice:
| Team Size | Channels | Relative Overhead |
|---|---|---|
| 3 | 3 | Low |
| 5 | 10 | Manageable |
| 8 | 28 | Moderate |
| 12 | 66 | High |
| 20 | 190 | Very High |
| 50 | 1,225 | Extreme |
This is why McConnell and Brooks both emphasize keeping teams small. Every person you add doesn't just add their own productivity — they add communication overhead to every existing member.
Staffing Constraints and Their Impact
Beyond Brooks's Law, real projects face staffing constraints that limit what's possible:
- Availability: Key specialists may be shared across projects
- Skill match: More developers doesn't help if they lack domain expertise
- Physical limits: Some work is inherently sequential (database schema must be designed before ORM code)
- Tool constraints: License limits, CI/CD capacity, environment availability
McConnell recommends planning for a staffing ramp: start with a small senior team for architecture and design, then bring on the full team for construction. Never front-load a project with its peak staff count.
The mythical man-month: why time and people aren't interchangeable
The "man-month" (or person-month) as a unit implies that people and time are interchangeable: 1 person for 12 months = 12 people for 1 month. This is only true for work that is perfectly partitionable with zero communication cost — which virtually never applies to software.
McConnell shows that for typical software projects, the schedule equation's cube-root relationship means that a 12-person-month project might take:
- 1 person: ~12 months (if they could do it all)
- 2 people: ~7 months (not 6!)
- 4 people: ~5 months (not 3!)
- 8 people: ~4 months (not 1.5!) — and this may already exceed the compression limit
The cube root means you get diminishing returns very quickly. This is why the schedule equation is so powerful for setting realistic expectations.
Key Takeaways
What to Remember
- Function Point Analysis measures software size by what it does, not how it's coded. Five function types: External Inputs, Outputs, Inquiries, Internal Logical Files, and External Interface Files. It is technology-independent.
- Effort scales non-linearly with size. The diseconomy-of-scale exponent (typically 1.05–1.20) means larger projects require disproportionately more effort due to communication and integration overhead.
-
The Basic Schedule Equation:
Schedule = 3.0 × StaffMonths^(1/3). This cube-root relationship is the most validated finding in software estimation. - The 25% compression wall is real. You cannot compress a nominal schedule more than 25% regardless of resources. Attempting more leads to defects, burnout, and paradoxically longer schedules.
- Brooks's Law endures: Adding people to a late project makes it later. Communication channels grow as n(n-1)/2. Ramp-up costs are real. Time and people are not interchangeable.