Before the Project

Core idea

Most projects are won or lost before the code starts

The topic pivots from the act of coding to the conditions that surround it. Thomas and Hunt's claim is that a disproportionate amount of project outcome — success, failure, slog, delight — is determined by what happens before anyone writes a line. The wrong requirements get built. The "impossible" puzzle is treated as impossible instead of constrained. The team works in isolation instead of together. The "agile process" is performed without the essence of agility being practiced. Each of the four topics in this topic is a discipline for getting the pre-coding conditions right.

Requirements are a process, not a document

The topic's most quoted reframe is on requirements. The traditional model — gather requirements, document them, hand them to engineering — assumes requirements exist somewhere fully formed, waiting to be picked up. They don't. They are buried under assumptions, politics, and ignorance, and they only become real through iteration with users who didn't know what they wanted until they saw a working approximation.

Tip 72: Work With a User to Think Like a User.

Pragmatic Programmers therefore treat requirements as an ongoing collaboration, not a one-time intake. The output is not a spec document; the output is a working system that progressively reveals what the user actually meant.

Why it matters

Wrong-target software is the most expensive kind

A system built precisely to the wrong specification is more wasteful than a system that fails to build at all. The team did the work, the code shipped, the users didn't want what was built — and now there's both a maintenance burden and a missing solution to the real problem. The cure is not better requirements documents. The cure is shorter feedback loops between the people who think they know what they want and the engineers who can show them what they actually meant.

"Impossible" is almost always "constrained"

Most problems labeled impossible in software are not impossible; they are constrained by an assumption nobody has questioned. The topic teaches the discipline of finding and questioning the assumed constraints. It's a perceptual move more than a technical one — but it's the move that distinguishes engineers who unblock teams from engineers who escalate.

Key takeaways

The topics in this topic

Topic 45 — The Requirements Pit

The topic's longest topic, and its most countercultural. The word gather suggests requirements are mushrooms — they exist, you pick them up. The reality is that they are usually discovered through dialogue with people who didn't know they had them.

Tip 73: Don't Gather Requirements — Dig for Them.

The authors' canonical example: a client says "shipping should be free on orders over $50." The naive engineer writes the rule and ships it. The Pragmatic Programmer asks: does $50 include tax? Does it include current shipping charges (because if so, customers can game it by selecting overnight shipping on a $25 item)? Paper books, ebooks, mixed? Domestic, international? Will the threshold change? Each question surfaces a hidden assumption that, if left buried, becomes a bug or a customer-support escalation.

Their model of the requirements process:

1. The client states a need — usually incomplete, often a solution dressed as a requirement.
2. You explore the consequences — asking the edge-case questions that flush out assumptions.
3. You feed back what you found — usually with examples or mockups, so the client can react to something concrete.
4. They refine their thinking — usually because seeing the consequences clarifies what they actually meant.
5. Repeat continuously, throughout the project — because the next round of feedback reshapes the next iteration.

Tip 74: Work With a User to Think Like a User.

Other practices the topic recommends: walk in the client's shoes (spend a day doing the job your system will support), distinguish requirements from policy (code the general case, encode the policy as data), document with working code wherever possible (the only spec that doesn't lie is the running system), and don't over-specify ("perfection is achieved not when there is nothing left to add but when there is nothing left to take away").

Topic 46 — Solving Impossible Puzzles

When a problem feels impossible, the move is not heroism — it is examining the constraints. Most impossibilities are accidents of assumed limits that, once questioned, dissolve. The classic puzzle the authors use is the nine-dots problem: connect nine dots with four straight lines without lifting your pen. The "impossibility" exists only if you assume the lines must stay within the square the dots form. They don't. The solution requires lines that extend past the perimeter.

Tip 75: Work Out the Degrees of Freedom.

The discipline:

• List every constraint, explicit and implicit. "Must use Postgres" — explicit. "Must run on this server" — implicit. "Must complete in one transaction" — implicit. Write them all down.
• For each one, ask: is it real? Many constraints are assumed, not required. Often the team decides one was a preference, not a hard rule.
• Relax constraints one at a time. A problem that was infeasible under five constraints is often trivial under four.

Tip 76: Don't Think Outside the Box — Find the Box.

The other half of the discipline: when truly stuck, switch context. Walk away, talk to someone outside the project, sleep on it. Many impossible puzzles unlock the moment you stop staring directly at them. The conscious mind keeps trying the same approach; the nonconscious mind finds new ones if given space.

Topic 47 — Working Together

Pragmatic Programmers favor actual collaboration — solving problems together at the keyboard — over the synthetic kind that consists of cc'd emails, meetings, and shared requirements documents. The topic advocates pair programming (two developers, one workstation, switching driver-navigator roles) and mob programming (a whole team around one screen, taking turns) as practices that produce better designs than solo work, faster than they look like they should.

Tip 77: Pair to Code; Mob to Explore.

The mechanism: a second mind in the room catches coincidence, fights naming drift, asks the questions the first mind would have skipped. Mob programming amplifies this for hard problems where a single pair's blind spots wouldn't catch the bug. The cost — two (or seven) people for one workstation's output — is misleading; the throughput is similar to solo work because the resulting code needs less rework and the team learns faster.

The topic is also explicit about what isn't working together: long meetings, document handoffs, asynchronous-only communication. These have their uses, but they are not substitutes for two engineers leaning at a screen working a problem in real time.

Topic 48 — The Essence of Agility

The topic closes on its sharpest target: the equation of agile methodologies with agility. The authors argue that adopting Scrum, Kanban, or XP without understanding why the practices exist produces ceremonies without benefits — standups where nobody shares anything meaningful, retros where nothing changes, sprints that are just waterfall in two-week chunks.

Tip 78: Costs Less and Delivers More. (The essence: agility is what produces this. Not standups.)

The essence, restored to first principles: agility is a value loop.

1. Figure out where you are.
2. Make the smallest meaningful move toward where you want to be.
3. Evaluate where you ended up.
4. Repeat.

Every agile practice is a way to do this loop tighter, faster, more honestly. Standups exist to make state visible; retros exist to inspect and adapt; iterations exist to shorten the feedback cycle; user stories exist to keep the smallest move meaningful. When the practice is performed without the loop, the practice is theatre.

The authors offer two practical implications. First, don't pick an agile methodology and apply it. Pick the smallest set of practices that close your team's actual feedback loops, run them, adapt. Second, the team that improves the fastest wins, because compounding small adaptations dominates almost any one-time gain. Agility is not a phase; it is the metabolic rate of the team.

Mental model

Copy sourceZoom

Practical application

A pre-project discovery checklist

When kicking off any new project or major feature, walk through this:

1. Who is the user? Name them. If you can't, you don't have requirements, you have a wish list.
2. What does success look like in their terms? Not "deliver feature X" — "user can complete task Y in Z minutes."
3. What constraints do we assume? Which are real? List them all; cross out the assumed-but-not-required ones.
4. What's the smallest end-to-end thing we can ship that produces real feedback? A tracer bullet. A week of work, not a quarter.
5. Who pairs with whom, when? Schedule deliberate collaboration time, not just standups.
6. What's our feedback loop length? Days, weeks, months? Shorter is better. If it's months, find a way to make it weeks.

A team that can answer these six questions has done most of the hard work before any code is written. A team that can't is heading for a requirements-pit project.

When something feels impossible

A short protocol:

• Write down every constraint you're operating under.
• Mark each one: hard (truly immovable) or assumed (I just believed it).
• For each assumed constraint, ask: what changes if we drop it?
• Try to solve the relaxed version. If it works, negotiate the dropped constraint with the stakeholder.

Most "impossible" engineering problems are solvable in 20 minutes once an assumed constraint is questioned. The remaining genuinely-impossible ones are usually solvable with a different architecture, which the constraint-listing exercise tends to surface.

Example

The reporting feature that taught the team about its users

A SaaS team has been asked to build a "custom reporting" feature. The stakeholder describes it as a drag-and-drop UI where customers can build their own reports from any field in the database. Estimated work: nine months.

A Pragmatic team approaches it differently. First, the requirements pit: who is asking for this, and what do they actually do? The product manager arranges for two engineers to sit with three customers for an afternoon each. They discover that two of the three customers don't want a report builder — they want one specific report (revenue by territory, weekly, emailed Monday morning) that the current system doesn't produce. The third wants a different specific report. None of them want drag-and-drop; the PM assumed they would.

Now the impossible puzzle dissolves. The original constraint was "build a flexible custom report engine." The relaxed constraint is "ship the three reports the customers actually want." That's a week of work, not nine months.

The team works together — two engineers pair on each of the three reports, shipping one per week. After three weeks the customers are using all three. Feedback comes in: customer #2 wants a fourth report variant. Customer #1 wants to filter by region.

This is the essence of agility in action. Each piece of feedback is a small, concrete adjustment. The team responds in days, not in quarters. By month three, they've shipped seven reports, each one demonstrably used, and a small filtering UI that emerged from real usage rather than imagined needs. The custom-report builder was never built — because it was never needed. The team has, in three months, delivered the value the original nine-month project promised, plus learned enough about their users to estimate the next set of features in days instead of weeks.

The topic's whole argument is in that example: the pre-project disciplines didn't add overhead. They eliminated nine months of building the wrong thing.

Related lessons