Do The Simplest Thing That Could Possibly Work

I was reading these posters and the one on simplicity made me think. It brilliantly summarized it with a simple concept: do the simplest thing, not the simplistic one. But what is the difference?

Rules of Simplicity:

1. Runs all the tests
2. Says everything once and only once (DRY)
3. Expresses all the ideas you want to express
4. Minimizes classes and methods

Often it is said that the order is important, but I'm not so sure anymore. If you can get the tests to run, be DRY, and express all intent in one huge class with one huge method, then that is simple. Is it good OO design? Perhaps, but you need to apply the SOLID principles as well as simplicity to determine that.

I was recently involved in a design discussion for a piece of the system that had really gotten away from us. It had grown very large, and the designs and idioms for similar pieces were not consistent. It was, well is, time to refactor. One indication of the need to refactor was that a simple change in one part broke another part.

As we were drawing UML and discussing ways to fix what was broken, one colleague asked why we just didn't default a method return to true instead of false because that would fix the problem. It sounded so simple, but was it? Let's apply the rules:

1. The tests would all run. They currently did not. PASS
2. It was one change, in one place. PASS
3. Hmm, did it express all the ideas? MAYBE
4. Did not add any more classes or methods nor did it remove any. DRAW

Well, it was a very simple suggestion. One that would get us to green in the least amount of time. But was it the simplest thing that could possibly work? I'm going to say no, because the current code did not express everything we want to express, does not use the least number of classes and methods, and is not DRY. This is where don't leave broken windows comes into play. Doing the fix was simple, but leaving the broken windows was not.

Sadly, we did not discuss the simplicity of his solution, so a learning opportunity for us all passed by the wayside. It seems we can get so caught up in getting the next feature done that we forget to sharpen the saw, but that's another post.

The way to tell the difference between the simplest thing that could possibly work and the most simplistic is to apply all the rules of simplicity and see how you fair. If you don't pass them all, then it's simplistic. The key is taking the time to actually evaluate the solution. And think of two. You can't choose the simplest solution unless you can think of at least two.