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

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.