My wife has this shower curtain for SAT preparation in mathematics. It’s mostly for humor, but I suppose it might work for some. It reminds me of a clear example of the difference between simple and easy. Recall that agile suggests doing “the simplest thing that could possibly work” and describes “simple design” in terms of passing tests, good names, eliminating duplication and removing unnecessary complexity. One of our struggles in teaching simplicity to others is that they often believe that what’s easiest is what’s simplest. We don’t often have good examples, so when I find one, I feel I should share it.

So the shower curtain describes how to multiply binomials such as (x+5)(x+7) using the acronym FOIL for “first, outer, inner, last”. This is a mnemonic device to help students remember to multiply all four pairs of terms before adding them together. FOIL, as a mnemonic device, makes multiplying binomials easier (for some), but it is not simple. Simpler would be to apply the distributive law twice, like so:

= (x+5)(x) + (x+5)(7)
= x^2+5x + 7x+35
= x^2+12x+35

This is simpler because in order to do it, I only have to apply a more general technique (the distributive law) twice, rather than knowing both the distributive law and the FOIL mnemonic. FOIL, while easier, adds to the student’s cognitive load by making him remember two things that he could easily believe were different, even though FOIL is a special case of the distributive law. A student who learns these two techniques might never see the relationship between the two, and so taking the easier route is doubly bad: it adds cognitive load and gets in the way of seeing an important relationship between two seemingly different ideas.

We see this all the time in designs: two structures that look different are really the same, but you need to dig a little more deeply than usually to see the similarity. If we insist on piling “easy” design elements on top of one another, rather than looking underneath for the similarities and removing the superficial duplication, we might never take advantage of our chance to simplify the design. It’s not as easy right now, but simpler designs tend to put less cognitive load on the reader, and so actually cost less once they’re built.

If you have other good examples of the difference between simple and easy, please share them so we can make this concept clearer to those to whom we teach agile programming techniques.