Click here to view the complete list of archived articles
This article was originally published in the Winter 2002 issue of Methods & Tools
Extreme Programming as Nested Conversations - Page 4
William C. Wake, http://www.xp123.com
Emergence at the Code Level
One of the unexpected aspects of XP is its flipping around the development cycle from "analyze-design-code-test" to "analyze-test-code-design" (Ralph Johnson). One way to design is to speculate on the full design that will be needed. Another approach is to intertwine design and development. XP follows the latter approach: build a little something, then evolve and generalize the code to reflect the design.
Martin Fowler’s book Refactoring catalogs "code smells" (indicators of design problems) and "refactorings" (safe transformations that can address problems). These provide (usually) local improvements to code.
The team also looks for more global improvements. Pair swapping and shared ownership mean that people will be exposed to more areas of the code, so able to spot similarities among disparate sections. The team’s search for a metaphor (shared understanding of the system) can help this too.
Why is this emergence? Because simple rules (smells and transformations) lead to something perhaps unexpected: globally good design.
Lean Manufacturing
The automobile industry has moved from assembly lines to lean manufacturing. Traditional assembly lines "push product" as fast as possible; inventory is regarded as an asset. In lean approaches, a product is "pulled" from the system, and inventory is regarded as a source of waste.
XP’s approach to planning and implementation strives for "just in time" work.
Suppose a team is doing 100 stories, at the rate of ten per week. This might be the schedule for an XP team:
Because the team is completes the highest-value stories first, the earliest iterations are the most valuable.
Compare this to a strict waterfall:
At some level, there’s the same amount of total work (though my bet would be on the first team). But look at it from a flow perspective: we don’t see any results until stories come out of testing.
Think of a story as inventory. When it has been analyzed, designed, and coded, but not tested or deployed, it has a substantial investment at risk. The XP pipeline lowers the risk: a story gets everything done at once, and spends less time at risk.
Conclusion
XP challenges traditional software development processes in several ways: everything from how a team is structured to how code is implemented comes in for scrutiny. The XP practices represent an effective way to help a team learn what software is needed and develop that software, while respecting and valuing each person on the team.
Further Reading
More Agile Knowledge