XP Principles

Values tell you what's important. Practices tell you what to do. But how do you connect them? That's where principles come in.

Principles are the bridge. They're more concrete than values but more abstract than practices. When you're deciding whether to adopt a practice or modify it for your context, principles guide the way.

XP has many principles, but we'll focus on the most important ones.

Software is made by people, for people.

This principle reminds us that developers aren't interchangeable resources. People have needs:

• Safety (physical and psychological)
• Accomplishment (doing meaningful work)
• Belonging (being part of a team)
• Growth (learning and improving)
• Intimacy (close, trusting relationships)

XP practices should meet these needs. Pair programming meets belonging and intimacy needs. Test-driven development meets accomplishment and safety needs. Sustainable pace protects physical and mental health.

When a practice feels wrong, ask: "Is this violating human needs?"

Money matters. Time has value. Options have value.

XP takes economics seriously:

• Time value of money: A feature delivered today is worth more than the same feature in six months
• Options: Keeping choices open has value (hence avoiding over-commitment)
• Cost of delay: Waiting to deliver value has real costs

This principle supports small releases (deliver value early), incremental design (don't over-invest up front), and iterative planning (respond to what you learn).

It also supports sustainable pace: exhausted developers make expensive mistakes.

Every practice should benefit everyone involved.

The best XP practices are win-win-win:

• Tests help the developer (confidence), the team (documentation), and future developers (safety net)
• Pair programming helps both partners (learning, catching errors) and the code (quality)
• Simple code helps the author (faster to write) and readers (easier to understand)

Avoid practices that help one group at the expense of another. Documentation written only for compliance, never read by developers, fails mutual benefit. Code written to be clever rather than clear fails it too.

If a practice creates resentment, it probably violates mutual benefit.

Patterns that work at one scale often work at others.

XP applies the same patterns at different scales:

• Red-green-refactor (tests): Make it fail, make it pass, make it clean
• Plan-do-study-act (iterations): Plan the work, do the work, study the results, adjust
• Collect-group-vote (retros): Gather data, find patterns, decide actions

When you find something that works, try it at different scales. The planning game works for release planning and iteration planning. Code review principles work for design review and architecture review.

Start where you are and get better continuously.

XP doesn't demand perfection from day one. It demands movement. Start with what you can do today, and improve from there.

• Don't have tests? Write one test for the next bug you fix.
• Not pair programming? Try it for one hour tomorrow.
• No continuous integration? Commit more frequently.

The goal isn't to be "doing XP." The goal is to be improving. XP is a direction, not a destination.

This principle also supports failing safely. Experiments that don't work are learning opportunities, not failures.

Deliver value continuously, not in big batches.

This principle aligns XP with lean thinking and Kanban. Big batches hide problems. Small batches surface them quickly.

• Small stories (days, not weeks)
• Frequent releases (weekly, not quarterly)
• Continuous integration (hours, not days)
• Immediate testing (seconds, not hours)

Flow reduces work-in-progress, which reduces context switching, which improves focus and quality. It also gives customers value sooner and feedback faster.

Quality is not negotiable.

This seems obvious, but the implications are profound. XP says you can trade scope or schedule, but never quality.

This means:

• Tests are not optional when time is tight
• Refactoring is not a luxury
• Technical debt is not acceptable
• "Ship now, fix later" is not a plan

Why? Because quality is the foundation of speed. Poor quality creates bugs that slow you down. Poor quality creates code that's hard to change. Poor quality creates systems that are expensive to maintain.

Quality is the fastest way to go fast.

Take the smallest step that makes progress.

Big changes are risky. Small changes are safe. XP always prefers small steps:

• Write one failing test before writing any code
• Refactor one thing at a time
• Integrate after small changes, not big ones
• Release small increments, not big releases

Baby steps don't mean slow progress. A thousand small steps can cover more ground than ten big leaps—and with less chance of falling.

When you're stuck, ask: "What's the smallest thing I can do right now that makes progress?"