From AI Experiment to a Dependable Business Service
AI makes useful tools cheaper to create. A dependable business service still needs explicit rules, tested outcomes, a...
Fred Brooks: The Hard Part Was Never Typing
8 min read
The Screen Worked. The Agreement Was Missing.
03.11.2026, By Stephan Schwab
The demonstration is ready. The order form works, the confirmation arrives, and someone asks why the old team needed six months. Then the warehouse asks what happens when an order is cancelled after picking starts. Finance asks which price survives a correction. Suddenly the room needs decisions that no amount of typing would have supplied. Fred Brooks gave software development a vocabulary for that gap. His work helps explain both the excitement of faster code and the disappointment when a convincing demonstration meets the business it must serve.
He Had Managed the Mess Himself
Brooks's questions came from responsibility for a real system, including decisions he regretted.
Fred Brooks helped shape IBM’s System/360 and managed its OS/360 operating-system work. His account of software development grew out of that experience. In his 2007 oral history with Grady Booch, he recalls Thomas Watson Jr. asking him how managing hardware differed from managing software. Thinking through that question became the starting point for The Mythical Man-Month.
The interview also contains something more useful than a heroic career summary. Asked about his worst decision, Brooks describes transferring architectural responsibility from the architecture group to the operating-system manager. He names his own mistake. The person explaining why software projects go wrong had helped one go wrong himself.
That makes him a useful companion when another impressive tool arrives with the suggestion that the difficult part has finally disappeared. He gives us a way to examine the work underneath the promise.
Two Kinds of Difficulty, One Convenient Confusion
Making an implementation cheaper does not automatically settle what it must mean.
In No Silver Bullet, his 1986 paper, Brooks separated essential difficulty—the conceptual work of specifying, designing, and checking a system—from accidental difficulty in expressing and executing it. He identified complexity, conformity to other systems and institutions, changeability, and invisibility as enduring problems. His headline forecast concerned a single advance producing a tenfold improvement within a decade. It was no measurement of present-day AI.
Consider an invented wholesaler replacing orders taken by phone with an online service. Creating the form might be straightforward. Deciding when an order becomes a promise is another matter.
Sales treats the confirmation as a commitment. The warehouse treats it as a request until stock has been allocated. Finance treats it as provisional until the customer’s credit has been checked. All three departments can demonstrate that their interpretation has worked for years. All three can also point to a colleague who quietly resolves the awkward cases.
Now the software needs a rule. The colleague’s discretion must become an explicit decision, an exception someone owns, or a reason to keep part of the work manual. A developer who asks about this has discovered the job. Asking them to stop overthinking and finish the form merely ensures that somebody else’s assumption wins by default.
The code may be perfectly competent. The promise may still be wrong.
The Exception Is Part of the Product
An awkward case can reveal a missing agreement that the ordinary case conceals.
Stay with the cancellation. The customer presses the button while a warehouse worker is walking toward the shelf. Should the order disappear from the worker’s device? Should the worker acknowledge the cancellation first? What should the customer see while that acknowledgement is pending?
Suppose the warehouse connection drops. The customer has received a cancellation message, but the worker continues picking from a downloaded list. A courier collects the parcel. Now the company has shipped something it says no longer exists.
Those questions are implementation work as well as business work. They affect state transitions, stored records, messages, retries, and the screen used by the person trying to repair the mistake. The developer needs enough technical understanding to make the failure visible and enough access to the people involved to establish an acceptable response.
Someone might propose a simpler commercial rule: cancellation becomes a request once picking starts, and the customer sees that distinction immediately. That decision could remove several technical problems. It also changes the service the company offers. The people responsible for that service need to agree to it.
This is why an exception deserves more attention than the phrase “edge case” sometimes allows. The ordinary path can let several incompatible ideas coexist peacefully. The exception makes them meet.
A Prototype Can Improve the Thinking
Use a small working example to discover a wrong assumption before it spreads.
Brooks advocated refining requirements through prototypes and growing running software incrementally. He offered a practical route to learning, rather than a demand to finish all thinking before coding. That recommendation matters as much as the famous warning about miraculous tools. The original paper contains both.
For the wholesaler, build the smallest version that exposes the cancellation problem. Let one person place a sample order while another starts picking it. Cancel it halfway through. Interrupt the warehouse connection. Ask both people what they believe has happened, then compare their answers with the records the system kept.
The first useful result may be an uncomfortable conversation. Good. It happened before the company imported ten thousand customers and announced that ordering had been transformed.
Once the participants agree on the behavior, capture concrete examples in automated checks. Include the late cancellation, the lost connection, and a repeated message. Keep a small change moving through integration and release so the team can discover problems in its actual surroundings. Kent Beck’s feedback discipline supplies a useful companion here: learn while the change remains small enough to understand.
The work has advanced when people can explain and demonstrate what happens. The number of screens is a rather poor substitute.
AI Can Help With More Than the Typing
Ask the assistant to investigate a decision, then check its answer against the actual work.
Applying Brooks’s distinction to AI requires some care. An assistant can help formulate alternatives, trace an existing implementation, identify contradictory rules, and suggest experiments. Those activities can contribute to conceptual work. Treating every AI contribution as mere typing would miss much of its possible value.
In the cancellation example, give the assistant the agreed constraints and ask it to trace where cancellation currently affects stock, payment, and dispatch. Ask what happens if each message arrives twice or out of order. Ask it to compare immediate cancellation with a cancellation request and describe who bears the inconvenience in each design. Check the answers against source, actual interfaces, and the people handling orders.
An assistant can also draft a prototype that makes those alternatives easier to discuss. Cheap implementation becomes valuable because it lets the team test an idea it could previously only argue about.
But a plausible answer has no authority to change a customer’s entitlement or a warehouse worker’s responsibility. If the assistant fills a gap with a familiar convention, that convention remains a proposal. Running code can conceal the assumption just as effectively as a confident paragraph.
The useful boundary is between a proposition and evidence that it fits. Crossing that boundary still requires contact with the system and the people whose work it changes.
Complexity Deserves an Argument Too
Before accommodating a difficult rule, ask whether anyone still needs it.
Calling a problem essential can become its own excuse. Perhaps the wholesaler has six cancellation rules because six former managers each negotiated a special arrangement. Perhaps two interfaces exist only because nobody retired an old import. Preserving every inherited complication would make the new software an unusually expensive museum.
Ask which commitments are real, which constraints still apply, and which procedures the company is willing to change. Sometimes the best technical simplification starts with retiring a business exception. Sometimes the awkward rule protects a valuable customer relationship and must stay. The answer needs investigation; elegant code alone cannot supply it.
That also leaves room for ordinary, substantial gains. A better library, a repaired development environment, or an assistant handling repetitive changes can remove a painful amount of effort. The title’s provocation has a limit: implementation has real costs, and reducing them matters. The mistake is assuming those savings settle every other kind of work.
Mary Poppendieck made a related problem visible: a faster activity can leave the whole path slow. Here the unresolved constraint may be an agreement about what the software is supposed to promise.
Which Uncertainty Did You Remove?
Judge the next change by what you can now explain, demonstrate, and rely on.
Back at the wholesaler, the cancellation button now distinguishes a cancelled order from a request awaiting warehouse confirmation. The worker sees the pending request. Finance can trace the adjustment. A lost connection produces a visible unresolved state, and someone owns resolving it. The team has tested those transitions together.
That version may contain fewer features than the first demonstration. It contains a much better answer.
Brooks deserves another reading whenever the industry confuses an easier implementation with a finished understanding. His argument invites a question we can apply to each new tool and each new change: which part of the difficulty did this actually remove?
If the answer is repetitive implementation work, enjoy the saving. If it is an assumption exposed and corrected, better still. If nobody can say, the demonstration may simply have become more persuasive.
The warehouse will eventually ask anyway.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
