Chapter 1. The Coordination Problem, 1968 to Now

Learning objectives

After this chapter you should be able to:

Explain why the 1968 NATO conference named the field "software engineering," and what its report says the "software crisis" was and was not.
State Conway's, Parnas's and Brooks's formulations of the coordination problem and what each assumes about communication.
Map the topics of a software engineering course onto the coordination problem each addresses.
Describe five ways coding agents differ from the workers classical methods typically assumed, which differences are measured and which argued, and the four conditions for assurance.
Evaluate two readings of the absence of classical topics from courses on AI-assisted development, and state this book's thesis.
Record a baseline agent session in a work log, with a prediction written down in advance.

Opening case

A composite case, not a real engagement.

Part one. A regional health insurer replaces its claims system. The program runs 3 years with about 140 people in six teams: enrollment, provider contracts, claim intake, pricing, payments, and reporting. Each team has a lead, a backlog, a passing test suite, and a shared binder of interface specifications that every lead signed.

The chapter continues from here.

What the chapter covers

1.1 Garmisch, 1968
- 1.1.1 A conference named a discipline
- 1.1.2 What the crisis was, and was not
- 1.1.3 Communication, already
1.2 Three classical statements of the problem
- 1.2.1 Conway: structure follows communication
- 1.2.2 Parnas: divide by what you hide
- 1.2.3 Brooks: communication outruns headcount
- 1.2.4 What the three share
1.3 Software engineering as a coordination discipline
1.4 What agents change about the workers
1.5 The curriculum problem
1.6 The time horizon
1.7 How this book is organized

Lab and prediction

Lab: Baseline agent session

Feeds milestone M0. How the labs fit the project

A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.

Summary

Garmisch (1968) named software engineering as an aspiration. Its report describes a crisis of large systems: a gap between plans and results, estimates that missed by factors of 2.5 to 4, and difficulty making many people's work fit.
Conway, Parnas and Brooks are the classical statements of the coordination problem. All assume coordination by bandwidth-limited messages between people.
Software engineering can be read as getting many minds to build one system when none sees all of it, with the catalog topics as its tools. This is my framing, with limits.
Agents write fast, less often understand by writing, by default fill gaps without asking, can receive identical explicit context as well as messages, and leave accountability with the people who ship. Some of this is measured, some argued, all dated. Four conditions (Chapter 16) say when a checking role adds assurance.
Courses on AI-assisted development leave out estimation, life cycles, risk, change, and reliability. A syllabus study cannot say whether that costs anything; the thesis is that these topics matter more but cannot be taught unchanged.
Tools are the vehicle; the question to carry is what would have to change about agents for a conclusion to stop being true. Read Chapter 18, Sections 18.1 to 18.3, in week one.

Key terms

Coordination: the work of making the decisions of many workers fit together in one system.Also used in 2, 6, 7, 8, 10, 16, 17, 18
Coordination failure: a defect that lives between parts, where each part satisfies its builder's understanding and the understandings differ.
Software crisis: the disputed label some 1968 NATO participants gave to the gap between what large systems demanded and what methods delivered.
Conway's law: a system's structure tends to copy the communication structure of its builders (Conway 1968).Also used in 8
Coding agent: a model given tools to read and edit files and run commands.Also used in 4, 9, 15
Agent harness: the program that runs a coding agent, supplying tools, enforcing permissions, and looping until the task ends.Also used in 3, 14, 16
Levels of "done": code-complete, merge-ready, and integrated (this chapter's lab; Chapter 7).
Pre-registration: writing down a prediction or estimate, dated and unchanged, before the data exist.Also used in 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18

Connections

Where this chapter and another point to each other most often.

Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
In Chapter 2 he shows that a task that partitions but needs communication pays training costs, which grow linearly with headcount, and intercommunication costs, which grow as n(n − 1)/2: three workers have three pairs, ten have 45, twenty have 190.
Chapter 7: Project Management and Where Value Is Earned
In Chapter 7 he asks why a project with plentiful labor, time, and technology failed anyway.
Chapter 8: Coordination at Scale: Shared Context vs. Shared Messages
Chapter 8 teaches them in full; here is enough to recognize each.
Chapter 16: Roles and the Four Conditions for Assurance
Chapter 16 develops and tests them; earlier chapters cite them by name. > 1.
Chapter 17: Coordination Without Communication: The Bound and the Leak Test
The pilots show that the instrument can detect a leak, not how often production stacks leak; the 1,000-round runs are in preparation (Chapters 8 and 17).
Chapter 18: Running the Whole Life Cycle: The Engineer as Manager of an Agent Team
My hypothesis is that attention, decisions and verification are what coordination is spent on, so the framings overlap (Chapter 18). ## 1.5 The curriculum problem Geng et al.

See it on the map

01 The Coordination Problem, 1968 to Now