Organizing a Software Project

The four forces: scope, time, cost, quality

Every project balances four things:

• Scope — what will be built;
• Time — when it will be ready;
• Cost — people, money, infrastructure (including AI-service bills);
• Quality — how well it works (the quality attributes of Chapter 1).

They are connected. If the deadline is fixed (the semester ends in week 15) and the team is fixed (five students), the only honest variables are scope and quality. Teams under pressure usually cut quality silently (no tests, no reviews); good teams cut scope openly, using the MoSCoW priorities of Chapter 4.

Team roles and structure

In StudyBuddy's Scrum team (Chapter 2): Lina is the Product Owner (what and why), a Scrum Master role rotates between members (how the team works), and everyone is a Developer. Many teams also have a tech lead (the person who keeps the technical design coherent) — a role, not a boss.

Good teams are small (often 3–9 people), cross-functional (they have all the skills to deliver: backend, mobile, testing, UX) and stable (the same people for months).

Conway's law (Melvin Conway, 1968): organizations design systems that mirror their own communication structure. If StudyBuddy had a "web team" and an "Android team" that never talk, it would end up with two different backends and inconsistent rules. Teams can use this deliberately (the "inverse Conway manoeuvre"): organize teams around the architecture you want.

Brooks's law and communication paths

In The Mythical Man-Month (1975), Fred Brooks stated Brooks's law: "Adding manpower to a late software project makes it later." Three reasons:

1. Ramp-up: new people need weeks to learn the code, the tools and the domain — and the experienced people must teach them instead of working.
2. Communication overhead: the number of possible communication paths between n people is n(n − 1) / 2. Five people: 10 paths. Eight people: 28 paths. Fifteen people: 105 paths.
3. Limited divisibility: some tasks cannot be split. "Nine women cannot make a baby in one month."

This is why "person-months" are a dangerous unit: 6 people × 2 months is not the same as 2 people × 6 months.

Estimation: why it is hard

Estimates are predictions made with incomplete information. Barry Boehm (and later Steve McConnell) described the cone of uncertainty: at the very beginning of a project, estimates can be wrong by a factor of about 4 in either direction (a "6-month" project may take 1.5 or 24 months). The range narrows as requirements, design and code become known.

Consequences: give estimates as ranges ("8–14 weeks"), re-estimate as you learn, and never treat an early estimate as a promise.

Common techniques:

Planning poker uses a Fibonacci-like scale because big items are less certain — the gaps grow. Revealing cards at the same time prevents anchoring: if the most senior developer says "3" first, everybody else drifts toward 3.

Velocity. If the StudyBuddy team completed 18, 22 and 20 points in its first three Sprints, its average velocity is 20. A backlog of 100 remaining points needs about 100 ÷ 20 = 5 more Sprints. Velocity is a planning tool for the team, not a performance score: comparing velocities between teams is meaningless (their points are different), and pressuring a team to "increase velocity" only inflates the estimates.

Three-point estimation. For "Buddy integration": O = 4 days, M = 7 days, P = 16 days → E = (4 + 28 + 16) / 6 = 8 days, SD = (16 − 4) / 6 = 2 days. Notice that E is more than the most likely value, because the pessimistic tail is long — that is typical of software. For several independent tasks, add the expected values, and add the variances (SD²), not the SDs: total SD = √(sum of SD²). A range like E ± 2 SD gives roughly 95% confidence.

Basic COCOMO (Boehm, 1981) for small, familiar ("organic") projects: effort E = 2.4 × KLOC^1.05 person-months and schedule D = 2.5 × E^0.38 months. For 10,000 lines: E ≈ 2.4 × 10^1.05 ≈ 26.9 person-months, D ≈ 2.5 × 26.9^0.38 ≈ 8.7 months. Such models are old and rough, but they show a lasting truth: effort grows faster than size.

Planning with dependencies: the critical path

Some tasks must wait for others: StudyBuddy's "Buddy answers" needs "upload course files" and "AI service wrapper" first. Draw tasks as a network with durations and dependencies. The critical path is the longest chain of dependent tasks from start to finish; its length is the shortest possible project duration. Any delay on a critical task delays the whole project; tasks off the critical path have slack (float).

Earliest finish times: A=3, B=7, C=8, D=6, E=max(8,6)+7=15, F=max(7,15)+1=16. The critical path is A → C → E → F (16 days). Login (B) has 8 days of slack: it can start late without delaying the release. D has 2 days of slack.

Risk management

A risk is an uncertain event that, if it happens, affects the project. Risk management is a loop:

1. Identify — brainstorm, check lists of common risks, look at past projects.
2. Analyse — estimate probability and impact; exposure = probability × impact.
3. Plan a response:
   • Avoid — change the plan so the risk cannot happen (don't use the untested library);
   • Mitigate — reduce probability or impact (prototype early, add tests, cross-train);
   • Transfer — give it to someone better placed (a hosting provider's service-level agreement, insurance);
   • Accept — consciously live with it, often with a contingency plan.
4. Monitor — review the risk register every Sprint; risks change.

Total exposure (the sum, here 22.2 days) is a rough expected delay — a sensible size for a schedule buffer.

Collaboration: Git, pull requests and code review

Version control is the team's shared memory. Two common workflows:

• Feature branches + pull requests (PRs): each change is developed on a short-lived branch, then a PR is opened; the CI pipeline runs; a teammate reviews; the change is merged into main.
• Trunk-based development: everybody integrates small changes into main at least daily (hiding unfinished features behind feature flags). Research by DORA links it to higher delivery performance.

Either way: small, frequent changes. A 50-line PR gets a careful review; a 2,000-line PR gets "looks good to me".

Good code-review practice:

• Review for correctness, readability, tests, security and design fit — not personal style (let an automatic formatter handle style).
• Keep PRs small and focused; describe why, link the story or requirement ID.
• Comment on the code, not the person; ask questions ("What happens if the list is empty?").
• The author owns the change; the reviewer shares responsibility for letting it in.

Team health: psychological safety and the bus factor

Google's Project Aristotle (2015) studied 180 of its teams and found that the most important factor in team effectiveness was psychological safety: team members feel safe to admit mistakes, ask "stupid" questions and disagree without being punished. In an unsafe team, people hide problems until it is too late — exactly the pattern in many failures of Chapter 1.

The bus factor (or truck factor) is the smallest number of people who would have to disappear (e.g., "hit by a bus") before the project stalls because nobody else understands critical parts. A bus factor of 1 is a major risk. Pair programming, code reviews, documentation and rotating tasks raise it.

The AI angle: organizing projects with AI

Estimation. AI assistants make some tasks much faster and others slower (Chapter 1's evidence), which widens uncertainty for a while. Estimate AI-assisted work the same way — relative size, measured velocity — and let data, not enthusiasm, change the numbers. Beware of anchoring on AI estimates: an assistant that says "this will take 2 hours" pulls the team's planning-poker cards down, although it knows nothing about your code base.

New risks for the register: the AI provider changes prices, limits or model behaviour; a model is retired; generated code has licence or security problems (Chapters 10 and 12); student data leaks through prompts (Chapter 11). Wrapping the AI provider behind the team's own interface (Chapter 6) mitigates several of these at once.

Comprehension debt and the bus factor. When large amounts of code are generated and merged without being deeply understood by anyone, the effective bus factor for that code can be zero: nobody on the team can safely change it. Code review rules from Chapter 2 ("the committer can explain every line") are also a knowledge-sharing practice.

Helpful uses: summarizing long PRs and meeting notes, drafting risk lists for the team to evaluate, producing first drafts of release notes, finding which files a change will touch (impact analysis). The decisions — commitments, priorities, risk responses — stay with the team.

Key takeaways

• Scope, time, cost and quality are linked; with fixed time and team, cut scope openly, not quality silently.
• Small, cross-functional, stable teams; Conway's law: systems mirror communication structures.
• Brooks's law: adding people to a late project makes it later (ramp-up, n(n−1)/2 paths, indivisible tasks).
• Early estimates can be off by ×4 (cone of uncertainty): give ranges and re-estimate. Use planning poker, velocity, three-point E = (O + 4M + P) / 6, and treat COCOMO as a rough check.
• The critical path is the longest dependency chain; it sets the minimum duration; other tasks have slack.
• Risk management: identify, analyse (exposure = P × impact), respond (avoid, mitigate, transfer, accept), monitor in a risk register.
• Small PRs, CI, respectful reviews focused on correctness, tests, security and design.
• Psychological safety makes problems visible early; raise the bus factor with pairing and reviews.
• AI widens estimation uncertainty, adds new risks (provider changes, leaks, licences) and can create comprehension debt — keep humans able to explain the code.