Xp Yagni Pitfalls

XpPitfalls

Solution: Don't Be Stupid.

Solution: RefactoringTrumpsYagni. It's more important to maintain code quality (a Developer right) than to increase business value by adding a feature (a Customer right). But note also that adding a feature too early may actually decrease overall velocity, by reducing code quality, thus reducing business value (or more precisely, reducing the rate of increase of business value).

The attitude that the Developer's rights trump the Customer's rights almost sounds like its own XP pitfall. Alternatively stated: It's more important to maintain the customer's right to "change your mind, to substitute functionality, and to change priorities without paying exorbitant costs" (CustomerBillOfRights) than to increase business value by adding a feature.

Solution: Often, refactoring before implementing a feature -- that is, sitting down with a new story, and instead of starting with a test, starting with a refactoring of the areas of code that will need to be altered -- will actually make it much easier to implement that feature.

Solution: Realize that YAGNI and Refactoring ARE IN NO WAY OPPOSED. They never come into conflict, so there is never a need for one to "trump" the other. They are both implied by Assume Simplicity, applied at different times relative to the code in question:

I guess the confusion arises when folks assume that refactoring implies introducing generality, which is not the case. Sometimes refactoring involves evolving the code from several special cases to one general case; but if introducing generality makes the code more complex, that ain't refactoring, and you ain't gonna need it. -JustinSampson

Solution: "Simple" in "the simplest thing" refers to cleanliness of design, not "minimal changes from whatever I happen to have right now." The latter has its place (see thrashing, above), but if taken too far, everything turns into molasses. -JimKingdon?


EditText of this page (last edited December 1, 2003) or FindPage with title or text search