Extreme Programming Experiences: Part 1 of 5: Do The Simplest Thing That Could Possibly Work

30 05 2009

Do The Simplest Thing That Could Possibly Work

This does not mean “do the least work possible”. Doing the least possible is not XP, it is hackery, which is the methodology that leads to a Big Ball of Mud.

You do want to do the least work possible in between the Red and Green steps, perhaps even by following the Pair Programming Ping Pong Pattern, a.k.a. The Pair Programming TDD Game.

But once you reach Green, you still need to Refactor Mercilessly. That step obligates you to eliminate duplication (Don’t Repeat Yourself / Once and Only Once / the Zero One Infinity Rule) and to make sure that the code Does The Simplest Thing That Could Possibly Work.

This is very important, because this is how you avoid AddingEpicycles. That is, if you skip the Refactor stage and just keep on doing Red-Green over and over, the code and tests quickly become very hard to work with, because you’re just hacking on top of a design that no longer fits the requirements. Pretty soon you will find that your feature velocity has dropped dramatically, because it’s so darn hard to make a simple change without breaking pre-existing tests.


Actions

Informations

One response to “Extreme Programming Experiences: Part 1 of 5: Do The Simplest Thing That Could Possibly Work”

30 05 2009
Pervasive Code » XP Experiences: Part 4 of 5: Technical Debt and Cruft (01:15:58) :

[...] All of these mean that at some point you cut corners on refactoring. Ugly test setup code isn’t The Simplest Thing That Could Possibly Work. [...]

Leave a comment

You can use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>