Chapter 7. XP, Simplicity, and Incremental Design
I’m not a great programmer; I’m just a good programmer with great habits.
Kent Beck, creator of XP
The goals of XP go beyond simply getting the team to work better. The larger goal of XP—of its practices, values, and principles—is to help teams build software that can be extended and changed easily, and to help those teams work, plan, and grow together in an environment that accepts and embraces these changes.
Adopting XP means more than just using pair programming for constant code reviews, or test-driven development to increase test coverage. Higher quality and getting along better with your teammates are great by-products of XP, and they help achieve the main goal. Those things are good, and they change the way that the team builds software, but they don’t fundamentally change the design of the software.
It’s worth repeating: an important goal of XP is software that can be changed easily. Teams can embrace change when they build software that is easier to change. This has a profound impact on how a good XP team approaches code and software design.
This also points to one of the keys to getting into the right mindset for XP: truly believing that practices you learned about in Chapter 6 like test-driven development, pair programming, and slack help you and your team to think about software design differently—and that leaving those practices out can lead you to build an inferior codebase that’s difficult to change.
In this chapter, ...
Get Learning Agile now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
