Extreme Programming Pocket Guide

Chapter 17. Do the Simplest Thing That Could Possibly Work

The phrase Chapter 17 is a reminder to balance functionality with simplicity. Ideally, code is designed and implemented as simply as possible while passing all tests. Comprehensive tests anchor the code to its necessary behavior. Merciless refactoring revises the code into its simplest possible representation.

Diligently practicing simplicity invests developer time in the customer’s current need, where it counts the most. Do what you need to do. Solve the current problem. Implement it simply. Make it work, then clean it up. Leave the whole system as simple as possible.

XP purposefully leaves “simplest” vague. It’s up to you to decide what is appropriate in each situation. Maybe using a library or reusing code elsewhere in the system is the simplest thing. The simplest thing may be refactoring another piece of code into a reusable class to use for the current task. Simplicity usually means not building in unnecessary flexibility; don’t add bells and whistles you don’t need.

“Simple” is different from “quickest to write” and very different from “the first idea that comes to mind.” Discovering the simplest possible solution is difficult. It’s okay to settle for simple enough, especially since you will refactor later. Simplify further when you come up with a better idea.

Simple code is easier to write after you break the habit of guessing ahead at future needs. Follow the story and task cards. Avoid the temptation to ask “what if?” ...