Chapter 8 — Before the Project
Topics 45–48 | Pages 403–434
Core Idea
Before writing a line of code, you need to understand what to build, navigate constraints, work collaboratively, and embrace genuine agility — not just the appearance of it.
Topic 45 — The Requirements Pit (p405)
Tip 75: No One Knows Exactly What They Want
Tip 76: Programmers Help People Understand What They Want
Tip 77: Requirements Are Learned in a Feedback Loop
Tip 78: Work with a User to Think Like a User
Tip 79: Policy Is Metadata
Tip 80: Use a Project Glossary
Requirements are not discovered — they are developed through exploration and feedback. The client’s initial statement is an invitation to explore, not a specification to implement.
Requirements vs. Policy:
- Requirement (what it must do): “Only authorized users may access employee records”
- Policy (current business rule, subject to change): “Only supervisors and HR may access employee records”
Policy should be metadata — implement the general case, put the specific rules in configuration. This way when policy changes, you update data, not code.
Requirements vs. Architecture vs. Design:
Requirements are need, not implementation. “The app will be organized as front-end/back-end” is not a requirement — it’s a design decision. Capture needs; let design emerge from them.
Good requirements practices:
- Ask edge-case questions early (the “$50 free shipping” example)
- Use prototypes and mockups as feedback tools, not sign-off documents
- Write user stories on index cards — short forces clarification
- Work with users directly (shadow them, sit with them); this builds trust and surfaces real needs
- Maintain a project glossary — shared vocabulary prevents costly misunderstandings
- Watch for requirements creep in iterations — make scope changes visible
Overspecification is a trap. Good requirements are abstract; they capture the semantic invariant (the business need), not the implementation.
Topic 46 — Solving Impossible Puzzles (p418)
Tip 81: Don’t Think Outside the Box — Find the Box
When a problem seems intractable, the issue is usually that you’re assuming constraints that don’t actually exist. The key is to identify which constraints are absolute and which are preconceived.
Process:
- Enumerate all possible avenues — don’t dismiss any immediately
- Challenge each constraint: “Is this actually required, or do I just assume it is?”
- Prove (not guess) which constraints are real
- Prioritize constraints; fit smaller ones within the most restrictive ones
When stuck: step away. Conscious reasoning is slow and tunnel-visioned. The subconscious associative brain often produces the solution when you walk, sleep, or talk about something else.
“Fortune favors the prepared mind” — your subconscious needs raw material. Feed it with varied experiences, reading, and the engineering daybook.
Topic 47 — Working Together (p424)
Tip 82: Don’t Go into the Code Alone
Conway’s Law: Organizations produce systems that mirror their communication structures. Teams that don’t talk produce siloed systems. Including users in the team produces software that reflects their needs.
Pair programming: One types, one thinks at a higher level. Both contribute. Benefits: fewer bad habits, higher-quality code, knowledge sharing, immediate peer review.
Mob programming: Multiple people + one typist. Includes anyone helpful — users, testers, sponsors. Great for hard problems. Typist rotates every 5-10 minutes.
Team dynamics for collaborative coding:
- Build the code, not your ego
- Criticize the code, not the person
- Listen to understand, not just to respond
- Start small; run retrospectives to improve
Topic 48 — The Essence of Agility (p429)
Tip 83: Agile Is Not a Noun; Agile Is How You Do Things
Agile is an adjective, a way of operating — not a process to install. “Agile-in-a-box” products miss the entire point.
The Agile Manifesto values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
“There can never be an agile process” — because agility means responding to unknowns you encounter after you set out. Any fixed process, by definition, can’t be agile.
The agile recipe:
- Work out where you are.
- Make the smallest meaningful step toward where you want to be.
- Evaluate where you end up, and fix anything you broke.
- Repeat — at every level, recursively.
This loop applies at every scale: variable naming, design decisions, project direction. Apply it everywhere, always.
Why good design enables agility: If step 3 (“fix what you broke”) is expensive, you’ll skip it. Good design (ETC) makes the loop cheap to execute at every level. That’s why design and agility are inseparable.
Key Takeaways
- Requirements are not gathered — they’re developed through iteration and feedback. No one knows exactly what they want upfront.
- Requirements express need, not architecture. Policy is metadata.
- Impossible-seeming problems usually have assumed constraints that aren’t real — find the box before trying to escape it.
- Working together (pair/mob programming) produces better software and surfaces problems earlier.
- True agility = feedback loop at every level: make a step, evaluate, adjust. There’s no agile process — only agile thinking.