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.

4 Comments

  1. Francisco Trindade:

    Hi Steve,

    I kinda think that the simplest thing should be in reality the quickest thing that could possibly work. I dont like to introduce hacks into my code either, but that has more to do with the standards I have when coding than with the “simplest thing” concept itself.

    I like to think that way because that’s how it is perceived by the customer, who is paying for my development time. In my mind he probably would want to have the quickest thing that could be done, having in mind the quality standards that have to be achieved.

    Even because when you are aiming at the solution that is easy to understand and lacking in unnecessary complexity, you are probably doing the most complex thing that could possibly work, in terms of development time.

    Cheers,
    Francisco

  2. Steve Bockman:

    Francisco,

    Thanks for your feedback. I’m glad you brought up the subject of development time and cost.

    When developing a piece of code, it is important to consider the overall (not just the immediate) development cost.

    In keeping with my earlier definition of “simplest”, a solution that is easy to understand and lacking in complexity will result in code that is less costly to maintain over the long haul.

    In other words, a collection of inexpensive individual parts does not necessarily result in an inexpensive system.

    –Steve

  3. Justin Sampson:

    This quick vs. simple distinction reminds me of the Test-Driven Development “mantra” — Red, Green, Refactor:

    1. Write a test that fails, giving a “red bar”.
    2. Code the quickest / easiest way to a green bar.
    3. Clean up the mess you made.

    Kent Beck’s presentations in particular really stress the idea of getting to a green bar quickly, even if it means making a mess of the code. His point is, as I understand it, to spend as little time as possible with a “red bar”, since time spent with an outstanding broken test is a kind of risk — your safety net for modifying the code has a hole in it. Once the bar is green — all tests are passing — you’re free to spend as much time as needed to make the code simple and clean. And of course, in XP/TDD, taking that time is not just a freedom, it is a responsibility. :)

  4. Francisco Trindade:

    @Justin I think you are right on the spot. That’s the easiest way to find out how much effort to put in the code IMO.

    @Steve We are agreeing more than not. I just wrote the comment to point that “easy to understand and lacking in unnecessary complexity” can also be misunderstood if not thought carefully.

    Cheers
    Francisco

Clicky Web Analytics