Chapter 9 — Pragmatic Projects
Topics 49–53 | Pages 435–468
Core Idea
Individual pragmatic practices scale to teams and projects. This chapter covers what teams need to be effective: culture, methodology discipline, infrastructure, and the ultimate goal — delighting users.
Topic 49 — Pragmatic Teams (p437)
Tip 84: Maintain Small, Stable Teams
Tip 85: Schedule It to Make It Happen
Tip 86: Organize Fully Functional Teams
A pragmatic team is small (<10-12 members), stable, and high-trust. People know and depend on each other.
Individual practices applied at team scale:
| Individual Principle | Team Expression |
|---|---|
| No broken windows | Team collectively owns quality; no one gets to say “that’s someone else’s problem” |
| Boiled frog | Everyone monitors for scope creep, changing requirements, new environments — don’t assume someone else is watching |
| Knowledge portfolio | Schedule technical investment: maintenance, process improvement, tech experiments, skill building |
| DRY | Instant, frictionless communication prevents duplication of effort across team members |
| Tracer bullets | Teams build end-to-end; organize for full-stack delivery, not functional silos |
Fully functional teams: Avoid functional silos (separate frontend, backend, QA teams) that create gates, handoffs, and approval waits. Build teams that can deliver an entire feature from end to end. Include the skills needed: frontend, backend, DBA, QA all working together.
Automation: Teams should automate everything — formatting, testing, deployment. Manual procedures are inconsistent and don’t scale.
Team identity: Give the project a name, a logo. It sounds trivial but creates identity and shared investment.
Topic 50 — Coconuts Don’t Cut It (p446)
Tip 87: Do What Works, Not What’s Fashionable
Tip 88: Deliver When Users Need It
Cargo cult programming: Adopting the superficial artifacts of successful processes (Scrum ceremonies, Spotify squads, Netflix chaos engineering) without understanding the underlying principles. Like rebuilding an airport from coconut shells and palm fronds and wondering why planes don’t land.
The goal is not “to do Scrum” or “to do agile” — the goal is to deliver working software that gives users new capability at a moment’s notice.
Shorten the feedback loop relentlessly:
- Years → months → weeks → days → continuous delivery on demand
Continuous delivery doesn’t mean forced daily deployment. It means you’re capable of deploying whenever the business needs it. Getting there requires solid infrastructure (the Starter Kit).
Adopt practices by trying them. Pilot with a small team, keep what works, discard the rest. What works at Spotify or Netflix was developed for their specific context, size, and constraints. Your context is different.
Topic 51 — Pragmatic Starter Kit (p452)
Tip 89: Use Version Control to Drive Builds, Tests, and Releases
Tip 90: Test Early, Test Often, Test Automatically
Tip 91: Coding Ain’t Done ‘Til All the Tests Run
Tip 92: Use Saboteurs to Test Your Testing
Tip 93: Test State Coverage, Not Code Coverage
Tip 94: Find Bugs Once
Tip 95: Don’t Use Manual Procedures
Every project needs three foundations:
1. Version Control
Everything under VCS — not just code but config, deployment scripts, dotfiles, etc. VCS drives the build/release pipeline. Commits and pushes trigger builds and tests. Tags trigger releases. No hallowed build machine; builds are ephemeral, on-demand cloud instances.
2. Ruthless and Continuous Testing
Types of testing:
- Unit tests — modules in isolation; foundation of all other testing
- Integration tests — subsystems working together; contracts between components
- Validation and verification — does it actually do what users need?
- Performance / stress testing — does it meet real-world load requirements?
Testing the tests:
- Deliberately introduce bugs and verify tests catch them
- Chaos Monkey / saboteur testing at the system level
Code coverage is a poor proxy for test quality. What matters is state coverage — a 3-line function with two integer parameters has a million possible states. You can execute every line and still miss the one failing state.
Find bugs once: Every bug a human finds manually should be the last time a human finds that bug. Write an automated test immediately, every time.
3. Full Automation
Manual procedures are inconsistent, not repeatable, and don’t scale. Everything that happens more than once must be automated. Manual steps break the pipeline and introduce drift between environments.
Topic 52 — Delight Your Users (p462)
Tip 96: Delight Users, Don’t Just Deliver Code
Delivering working software on time isn’t enough. Users have a business problem to solve, not a software project to receive.
Ask early and continuously: “How will you know we’ve been successful a month/year after this project is done?”
The answer reveals the real measure of success — which is often about business outcomes (customer retention, data quality, cost reduction), not features.
Use these business expectations to:
- Ensure the whole team shares the same understanding of success
- Make decisions that move toward the real goal
- Challenge stated requirements that don’t serve the underlying objective
- Identify opportunities across the business that only developers can see (connecting disparate systems, insights from exposure to many departments)
True title: not “Software Developer” — Problem Solver.
Topic 53 — Pride and Prejudice (p465)
Tip 97: Sign Your Work
Craftspeople of earlier eras signed their work. Pragmatic Programmers should too — pride of ownership is the foundation of quality.
“I wrote this, and I stand behind my work.” Your name on a piece of code should mean: solid, well-written, tested, documented. A professional job.
Caveats: ownership should not become territorial. Code can be collectively owned (as in XP’s communal ownership); what matters is that someone takes responsibility, not that it creates fiefdoms. Treat others’ code with the same respect you want for yours.
Anonymity breeds sloppiness; accountability breeds quality.
Key Takeaways
- Small, stable teams outperform large groups — organize for trust and communication density.
- Schedule technical work (refactoring, experiments, learning) or it will never happen.
- Don’t copy process artifacts from other companies — copy their principles, adapted to your context.
- The Starter Kit is non-negotiable: VCS drives everything, tests run on every commit, nothing is manual.
- State coverage matters, not line coverage. Find bugs once — automate the test immediately.
- Your job isn’t to deliver code; it’s to delight users by solving their real business problems.
- Sign your work. Pride of ownership drives quality.