The Simplest Thing...
I don't know about you, but I find the concept of The Simplest Thing That Could Possibly Work to be pretty confusing. What is the simplest thing? And what does it mean "could possibly work?" -- I certainly hope that it works. Take for example:
- Is it simpler just to return null from this method? Or should we use a null object?
- Is it simpler to use an int here? Or would an Integer be better? Or a Long for that matter?
- Should I extract this code block out into a separate class? Or is it simpler to leave it where it is?
I'm sure that you can think of many more (and better) examples. These are the sorts of questions that we, as XP developers, ask ourselves or are asked by others many times each day. Now, we may have a strong preference for choosing one option over the other, but the honest answer is that until we look at the code and even try it out, it's pretty hard to know. So the answer to these questions is: "it depends"
One common piece of advice that I often hear is that it is important not to confuse the simplest thing with the easiest thing. This tells me that the simplest thing is not (necessarily) the easiest thing to do: simple things are hard. All well and good, but it still leaves me asking the question: what is the simplest thing?
Other common bits of advice that I've heard is that the simplest thing:
-
Has the fewest lines of code,
-
Is the easiest to read,
-
Has the least duplication,
-
Is well tested.
While these are useful words of advice in their own right, do they really help me identify the simplest thing? Not entirely. For one, these definitions are conflicting. To take a slightly absurd example, if my goal was to achieve simplicity by having the fewest lines of code, I could inline all my method calls into one long line. This would, of course, dramatically impact readability as I would have to scroll several screens horizontally to read the entire line. Would this be the simplest thing? Probably not. What about eliminating code duplication -- is that sufficient? Well, low duplication doesn't necessarily mean that the code is readable. And what about all those unit tests? Requiring every method to be invoked both by its dependencies and by the unit tests constitues a form of code duplication -- some have referred to this as XP's dirty little secret: for XP, the motto "once and only once" should be rephrased to "twice and only twice".
Now, these things only appear to be paradoxes if one loses perspective of why simplicity matters in the first place. As I mentioned in my previous post, XP values simplicity because it expects things to change, and simple things are easier to change than complex things. We strive for simplicity so that we can minimise the cost of changing things later. Fundamentally, all of these things (readability, duplication, tests, code quality) only matter if that code is ever going to change in the future (ie. it has to be maintained). If we can guarantee that no one is going to touch it (or read it) in the future then why go to all this effort? The problem is that we can't.
Focussing on embracing change as our underlying motivation helps us clarify what is meant by the simplest thing:
-
Fewer lines of code matters because less code makes it easier for us to identify what we have to change;
-
Readability matters because we accept that someone is going to have to understand and change the code;
-
Low duplication matters because it is simpler to change things in one place than in several;
-
Tests matter because they are the simplest way for us identify if our change broke anything.
Reframing these guidelines like this help us dispel the paradoxes that arise from trying to blindly follow them. In fact, I would go so far as to suggest that "The Simplest Thing That Could Possibly Work" is misleading because it doesn't explicitly identify why simplicity matters. Maybe renaming it to "The Simplest Thing To Possibly Change" would be more helpful...