To some folks, XP seems like just good common sense. So why the “extreme” in the name? XP
takes commonsense principles and practices to extreme levels.
â— If code reviews are good, we’ll review code all the time (pair programming).
â— If testing is good, everybody will test all the time (unit testing), even the customers
(functional testing).
â— If design is good, we’ll make it part of everybody’s daily business (refactoring).
â— If simplicity is good, we’ll always leave the system with the simplest design that supports its
current functionality (the simplest thing that could possibly work).
â— If architecture is important, everybody will work defining and refining the architecture all the
time (metaphor).
â— If integration testing is important, then we’ll integrate and test several times a day
(continuous integration).
â— If short iterations are good, we’ll make the iterations really, really short—seconds and
minutes and hours, not weeks and months and years (the Planning Game).
Preface of Extreme Programming, Embrace Change
To some folks, XP seems like just good common sense. So why the “extreme” in the name? XP
takes commonsense principles and practices to extreme levels.
â— If code reviews are good, we’ll review code all the time (pair programming).
â— If testing is good, everybody will test all the time (unit testing), even the customers
(functional testing).
â— If design is good, we’ll make it part of everybody’s daily business (refactoring).
â— If simplicity is good, we’ll always leave the system with the simplest design that supports its
current functionality (the simplest thing that could possibly work).
â— If architecture is important, everybody will work defining and refining the architecture all the
time (metaphor).
â— If integration testing is important, then we’ll integrate and test several times a day
(continuous integration).
â— If short iterations are good, we’ll make the iterations really, really short—seconds and
minutes and hours, not weeks and months and years (the Planning Game).