| Kent Beck has released a new edition of Extreme Programming Explained. This note discusses some highlights and compares it to the first edition. |
Quick Summary
The second edition of Extreme Programming Explained is out. This note is just a quick summary (read the original!), with some comments of mine in italics.
There’s an added value, Respect. There are more practices, organized as primary and corollary practices. Primary practices can stand alone; corollary practices need the support of other practices. These work together to make adopting XP be able to be more incremental than “try all these together.” This book suggests a simpler approach to planning. Finally, there’s good material on the philosophy and background of XP.
Even if you’re familiar with the first edition, this book gives you a better picture of what XP means.
XP
What is XP?
- a mechanism for social change
- a style of development
- a path to improvement
- an attempt to reconcile humanity and productivity
- a software development discipline
These point to more ambitious goals than “a dozen developers in a room” that the first edition mostly claimed.
What are its values?
- Communication
- Simplicity
- Feedback
- Courage
- Respect
“Respect” is listed as a new value.
What are its principles?
- Humanity: balancing individual and team needs
- Economics: built on the time value of money and the option value of systems and teams
- Mutual benefit: “the most important XP principle and the most difficult to adhere to”
- Self-similarity: make the small echo the large (and vice versa)
- Improvement
- Diversity
- Reflection
- Flow: from lean manufacturing, not from psychology – deliver a steady flow of value by engaging in all development activities simultaneously
- Opportunity: see problems as opportunities
- Redundancy
- Failure: “If you’re having trouble succeeding, fail.”
- Quality
- Baby steps
- Accepted responsibility
Practices
There are still practices in XP (more than ever). Now, they’re divided into primary practices and corollary practices. Primary practices are ones that are generally safe to introduce one at a time, or in any order. Corollary practices are riskier: they require the support of other practices.
The approach to introducing practices is a lot more gentle-sounding: there’s the idea that you can change yourself, not impose practices on others. Beck advises not changing too fast. This all sounds more gentle than “do all 12 practices” that came through from the first edition.
Primary Practices
These are generally similar to many earlier practices, turning up the knobs a little.
Sit Together: but “tearing down the cubicle walls before the team is ready is counter-productive”
Whole Team: a cross-functional team.
Informative Workspace: a workspace that meets human needs, and a place for big visible charts.
Energized Work: a reinterpretation of “40-hour week” and “sustainable pace”
Pair Programming
Stories: “units of customer-visible functionality.” And, “Every attempt I’ve seen to computerize stories has failed to provide a fraction of the value of having real cards on a real wall.”
Weekly Cycle: an iteration: plan, write tests & code.
Quarterly Cycle: plan a quarter using themes.
Slack: include things that can be dropped if you get behind.
Ten-Minute Build: automatically build and test everything.
Continuous Integration
Test-First Programming
Incremental Design
Corollary Practices
Real Customer Involvement
Incremental Deployment
Team Continuity
Shrinking Teams: a proposal to reduce teams by making one person as idle as possible, rather than easing the load on everybody. Another element derived from lean thinking.
Root Cause Analysis: the five whys.
Shared Code
Code and Tests: as the primary permanent artifacts.
Single Code Base: one code stream. “Don’t make more versions of your source code… fix the underlying problem.”
Daily Deployment
Negotiated Scope Contract
Pay-per-use: “money is the ultimate feedback”
First Edition Practices
For comparison:
The Planning Game: Quarterly Cycle and Weekly Cycle address this. The planning approach in 2/e is simpler.
Small Releases: Incremental Deployment and Daily Deployment carry this much further.
Metaphor: this was always the least well understood practice, and discussion of it has been more or less eliminated from this edition.
Simple Design: Incremental Design and to some extent Single Code Base.
Testing: Test-First Programming
Refactoring: Not called out; I think of it as part of Incremental Design.
Pair Programming
Collective Ownership: Now called Shared Code.
Continuous Integration
40-Hour Week: Energized Work, and to some extent Slack, cover this.
On-Site Customer: Sit Together, Whole Team, and Real Customer Involvement cover this area.
Coding Standards: Not called out explicitly; probably more of a consequence of Shared Code and Pair Programming.
As you can see, some are the same, some have a name change, and some (notably metaphor and the more programming-oriented practices of refactoring and coding standards) are not discussed.
Topics
Planning
There’s a strategy for all levels of planning:
- List the items
- Estimate
- Set a budget
- Agree on the work to be done (without changing estimates or budgets)
Planning should involve the whole team.
Beck now suggests estimating in real pair hours (two people working together for an hour). This is a shift from the relative estimates used before.
Testing
Testing is built around two principles:
- Double Checking (e.g., test and code)
- Defect Cost Increase (making it cheaper to fix it now)
The argument in 1/e about a flat cost of change curve is gone. Instead, the Defect Cost Increase is leveraged to identify testing as important.
Automated customer and programmer tests are important. Use test-first, at both levels.
Design
Design is incremental: “design always.” “Once and only once” is still important. Kent suggests these guidelines for simplicity:
- Appropriate for the intended audience
- Communicative
- Factored
- Minimal
He has a nice chart comparing design based on instinct, versus thought, versus experience. Sometimes an instinctual design may be good enough, other times, the thought design is good enough, other times experience is required.
“Designing software is not done for its own sake in XP. Design is in service of a trust relationship between technical and business people.”
“The price of this strategy is that it requires the discipline to continue investing in design throughout the life of the project and to make larger changes in small steps, so as to maintain the flow of valuable new functionality.”
Scaling
There are different types of scaling.
To scale according the number of people:
- Turn the problem into smaller problems
- Apply simple solutions
- Apply complex solutions if any problem is left.
Uses the “conquer and divide” strategy. “Chip away at complexity while continuing to deliver.”
Safety- and security-critical software may require some modest changes.
Philosophy
Taylorism
After Winslow Taylor. The consequences are bad, resulting from separation of planning from execution, and having a separate quality department.
Toyota Production System
“Every worker is responsible for the whole production line.”
Ongoing improvement comes from elimination of waste – kaizen.
“If you use a part immediately, you get the value of the part itself as well as information about whether the upstream machine is working correctly.” […] “The greatest waste is the waste of overproduction. Software development is full of the waste of overproduction.”
Applying XP
(Note: not “adopting” XP.)
There are many ways to start.
Change yourself first, then offer the fruit of that to others. “Continuous” learning is not really continuous.
Two types of groups find it easiest to start XP: those aligned with its values, and those in pain.
Purity
There’s not a binary answer to “Am I doing XP? “The goal is successful and satisfying relationships and projects, not membership in the XP club.”
Offshore
Think “multi-site,” not “offshore.”
“Jobs aren’t going in search of low salaries. Jobs are going in search of integrity and accountability.”
“Without dramatic improvement, though, the global market for software will stagnate as more attractive investments are found in manufacturing and biotechnology.” Kent’s been quoted as saying “All methodology is based on fear.” I think this sentence captures one of the fears XP is intended to address.
The Timeless Way of Programming
“Harmony and balance are the aims of XP.”
Community and XP
“A supportive community is a great asset in software development.”
Conclusion
The first edition was a manifesto to programmers. The new edition has a broader audience.
The practices are more extreme, the rhetoric less so. The mechanics of programming XP-style are a little less explicit (but there are certainly plenty of books out there on test-driven development, refactoring, and so on.) The philosophy shines through more clearly.
The result is a worthy follow-on.
Extreme Programming Explained, by Kent Beck and Cynthia Andres. Addison-Wesley Professional, 2004. ISBN 0321278658.
[Written January, 2005.]