The missing value in XP: Pragmatism
Pragmatism is implicit in Extreme Programming, although it is not explicitly recognized. For this reason, I believe that pragmatism deserves to be elevated to a fundamental value within XP
Pragmatism
As a philosophical movement, pragmatism emphasizes practical consequences and actionable knowledge in determining truth and value. According to Charles Sanders Peirce, one of its founders, pragmatism serves as a method to clarify concepts by examining their practical effects:
Consider what effects, which might conceivably have practical bearings, we conceive the object of our conception to have. Then, our conception of these effects is the whole of our conception of the object.
Peirce argues that an idea's meaning is found in its practical applications. Rather than judging ideas through abstract theories, we should evaluate them by their real-world impact. This core principle shapes pragmatism's emphasis on utility.
Building on Peirce's ideas, William James described pragmatism as a problem-solving approach where truth emerges from utility and real-world functionality:
The true is the name of whatever proves itself to be good in the way of belief, and good, too, for definite, assignable reasons. (Pragmatism, 1907).
James's interpretation expands pragmatism into decision-making. He argues that truth isn't fixed or universal, but rather a practical tool—something becomes "true" when it works to achieve specific goals. This perspective aligns naturally with agile practices, where teams use iterative feedback loops to keep what works and discard what doesn't.
Pragmatism reaches beyond philosophy, influencing fields like education, politics, and technology. John Dewey, another key thinker, emphasized pragmatism's focus on learning through experience and adapting to change:
The test of ideas, of thinking generally, is found in the consequences of the acts to which thinking leads.
Dewey contends that we must evaluate ideas and theories based on their actual outcomes. In software development, this could mean testing and refining processes through real-world feedback instead of blindly following idealized methodologies. His view emphasizes pragmatism's dynamic, iterative nature, which mirrors Extreme Programming's principles of continuous improvement and adaptability.
At its core, pragmatism strikes a balance—it avoids dogmatic adherence to ideals while maintaining grounded, ethical decision-making. This approach proves particularly valuable in fast-moving, uncertain fields like software development, where changing requirements and diverse perspectives call for practical solutions.
What is Extreme Programming (XP)?
XP, conceived in 1996 by Kent Beck during the Chrysler Comprehensive Compensation (C3) project, transformed software development through its focus on adaptability and collaboration. In his 1999 book, Extreme Programming Explained: Embrace Change, Beck formalized XP as a methodology that enhances software quality through rapid feedback, simplicity, and teamwork.
XP became a cornerstone of modern software practices. When Beck co-authored the Agile Manifesto in 2001, he wove XP's core ideas into what would become the Agile movement. The methodology's emphasis on iterative cycles, team dynamics, and customer collaboration shaped fundamental Agile principles.
XP transcends mere practices—it embodies a philosophy of work that embraces change while keeping people at its center. Its framework rests on values, principles, and practices, all working together to produce lasting, high-quality software.
XP Values
Let's examine XP's five core values and their practical implications through the lens of pragmatism.
Simplicity
XP advocates solving current problems directly, avoiding over-engineered solutions for hypothetical future scenarios.
Example: Writing the minimum code needed to pass a test and deliver value.
Pragmatism in this context means striking the right balance—recognizing when additional features would create unnecessary complexity while ensuring solutions meet immediate needs.
Beck's Insight: Beck writes, "The simplest thing that could possibly work," reflecting a pragmatic approach to balancing effort with outcomes.
Communication
Regular interaction between team members fosters alignment and prevents misunderstandings.
Example: Daily stand-ups and shared code ownership foster open communication.
A pragmatic approach keeps communication focused on solving concrete problems rather than getting lost in abstract discussions.
Beck's Insight: Beck emphasizes open conversations, recognizing that strong communication prevents small misunderstandings from derailing projects.
My take: we work in teams doing collaborative work if, we do not communicate properly and effectively and clearly, we will face some difficulties a long the way.
Feedback
Rapid feedback loops enable teams to learn and adapt quickly.
Example: Continuous integration catches bugs early, preventing costly downstream errors.
Pragmatism reinforces feedback as a tool for continuous improvement, linking actions to measurable outcomes.
Beck's Insight: Feedback is a mechanism for constant course correction, ensuring that teams stay on track without overcommitting to flawed assumptions.
My take: Feedback is also what allows us to grow and to continue becoming better professionals.
Courage
XP encourages teams to take calculated risks—such as refactoring code or embracing change—while pragmatism ensures these risks are well-reasoned and worthwhile.
Example: Having the courage to remove a feature when it no longer provides customer value.
Beck's Insight: Beck repeatedly stresses the importance of making bold decisions while maintaining thoughtful judgment.
My Take: We also need courage to raise our hands when something is wrong or doesn’t work as it should.
Respect
Teams thrive on mutual respect, acknowledging each member's unique contributions and viewpoints.
Pragmatism transforms respect from an abstract value into a practical tool for conflict resolution and team collaboration.
Example: Using the "disagree and commit" approach to resolve conflicts, where team progress takes precedence over personal opinions.
Beck's Insight: Respect, for Beck, is foundational to XP's human-centered philosophy, fostering collaboration without unnecessary friction.
My Take: we also need to respect ourselves, and don’t forget we are part of the team too.
Pragmatism in Kent Beck's Writing
Although Beck doesn't explicitly mention pragmatism in Extreme Programming Explained, his writing embodies its principles:
Focusing on Outcomes
The most important measure of progress is the delivery of valuable software.
This emphasis on concrete results rather than rigid processes reflects James's view that truth emerges from practical utility.
Iterative Learning
The more often you test your assumptions, the sooner you will discover what works and what doesn't.
Beck champions iterative feedback loops, echoing Dewey's emphasis on learning through direct experience and consequences.
Adaptability of XP Practices
XP has rules, but they are written in pencil, not carved in stone.
This flexibility reflects the pragmatic view that outcomes matter more than rigid processes.
The Relationship Between XP Values, Principles, and Practices
XP's framework is deeply interconnected:
Values are the "why"—they define a team's core motivations and priorities:
Communication: Fostering clear, open dialogue
Feedback: Enabling continuous improvement
Respect: Recognizing each member's contributions
Courage: Embracing necessary changes
Simplicity: Building only what is needed
Principles are the "how"—they bridge values and action
Practices are the "what"—the tangible actions
Without pragmatism, this methodology risks becoming rigid. For example, pair programming requires both technical collaboration and the courage to express different viewpoints. Pragmatism helps teams adapt these practices to their specific context and needs.
Conclusions
In software development, pragmatism serves as a bridge between theory and practice. It enables teams to advance toward shared goals while maintaining core principles. Being pragmatic means fostering collaboration to reach viable, ethical solutions where all voices are heard.
While Kent Beck never explicitly uses the term "pragmatism" in Extreme Programming Explained, the philosophy of pragmatism permeates his approach to XP. Beck repeatedly advocates for balancing principles with real-world constraints, adapting to circumstances, and focusing on outcomes that provide tangible value. His implicit pragmatism provides a methodology and even a philosophy for navigating the complexities of software development without compromising ethical or collaborative principles.
Consider a clear example: when two or more people need to reach an agreement but can't find a consensus despite their efforts. In such situations, the best approach is to either "disagree and commit" or find a middle ground—allowing us to achieve our objectives without becoming deadlocked. This principle extends well beyond software development, proving valuable across many different fields.
References
Beck, Kent. Extreme Programming Embrace the Change.
Pragmatism has permeated my own approach to helping make software development "hum" - I like what you've done here - and appreciate Garrick West's parallel observation and pointer here.
To your final example, when two or more people need to reach an agreement but can't find a consensus despite their efforts, Llewellyn Falco suggested a third ingeniously pragmatic solution that I think is captured by "stop talking, start doing": Llewellyn, in coaching mobbing (as it used to be called), proposed when facing such a blockage, to immediately start coding the least likely approach (and apologies to Llewellyn - I'm sure he characterized it better than "least likely"): if if works and it's good enough, we can move on; if if doesn't work, its adherents will have been gratified to have been heard and we can move on coding the other - and either way we'll have spent less time than we would have spent arguing approaches. Hearing him describe it, it so resonated. Ahhh, pragmatism.