What is “The Simplest Thing That Could Possibly Work”?
Anyone with even the slightest exposure to eXtreme Programming has heard the phrase “do the simplest thing that could possibly work.” While this precept is typically applied during the process of writing code, I’ve also heard it mentioned during design discussions. I bring it up myself during estimation sessions as a reminder to estimate the simplest implementation of a user story one can imagine.
I’ve also heard it misquoted as “do the easiest thing that could possibly work” and even “do the quickest thing that could possibly work.”
It’s not necessarily the easiest thing
Although the simplest thing that could possibly work might sometimes also be the easiest thing, it often is not. For example, the easiest thing might be to copy and paste a section of code in order to duplicate its functionality in another part of a program. But is that the simplest thing? I believe it is not.
It’s not necessarily the quickest thing
The simplest thing that could possibly work might sometimes also be the quickest thing, but there aren’t any guarantees. The use of short variable and method names might be quicker (because it saves typing time) than the use of longer, more meaningful names, but is it simpler? Again, I don’t think so.
What does simple mean?
Here’s my working definition: Something that is simple is neither complex (meaning having more parts) nor complicated (meaning difficult to understand).
In the first example above, the easiest thing is not the simplest thing because doing the easiest thing (rubber-stamping the code) introduces complexity.
In the second example above, the quickest thing is not the simplest thing because doing the quickest thing (using short names) introduces complication.
Conclusion
If you want to do the simplest thing that could possibly work, look for a solution that is both easy to understand and lacking in unnecessary complexity.
