TITLE: What is the Simplest Thing? AUTHOR: Eugene Wallingford DATE: June 18, 2007 4:18 PM DESC: ----- BODY: Tim Ottinger recently posted a blog entry on a problem that we all face: how to know what the simplest thing is when tying to do the simplest thing. Tim points out that what he finds simple may not match at all what others find simple, and vice versa. This is a problem whenever we are working collaboratively, because our decision becomes part of the common code base that everyone works with. But I think it's also a problem for solo programmers who want to remain true to the spirit of YAGNI and reap the benefits offered by growing a program organically in small steps. When I face this decision in my individual programming, I try to make the choice between two potential implementations based on the sheer effort I have to make today to make my program run with the new feature in it. This means ignoring the voice in my head that says, "But you know that later you'll have to change that." Well, okay then, I'll change it later. The funny thing is that sometimes, I don't have to change it later, at least not in the way I thought back then. Below a certain threshold of time and energy, I treat all effort as roughly the same. Often, one approach uses a base data type and the other uses a simple object that hides the base data type. I can often implement the former a small bit faster, but I can usually implement both quickly enough to have my feature running now. In such cases, I will usually opt for the object. Maybe this violates the spirit of doing the simplest thing that could possibly work, but I don't find that to be the case in practice. Even when I am wrong and make a change later, it is almost never to retract my object but to change the object's implementation. I almost always want my program to speak in the language of the problem domain, not the underlying programming language, and the object enables my program to do that. In this sense, my experience gibes with that of Kevin Lawrence, who coined an eponymous maxim to address a similar case:
If you ever feel yourself drawn toward writing a static method, obey Kevin's Maxim: "in an object-oriented language the simplest thing that could possibly work is an object."
The key is that we seek to defer non-trivial programming effort until the time spent making it will prove valuable in today's version of the system. Whenever pair programming is involved, the desire to do the simplest thing becomes the subject of a pairwise conversation. And as pairs form and dissolve over time, the group's collective wisdom can become part of the decision-making process. The goal of focusing the time spent of delivering value today remains the same, but now we can draw on more experience in making the decision. Ultimately, I think the value in having YAGNI and Do the Simplest Thing that Could Possibly Work as goals comes back to something that came up in my last post. The value of these guidelines comes not from the specific answers we come up with but from the fact that we are asking the questions at all. At least we are thinking about giving our customer fair value for the work we are doing today, and trying to keep our program simple enough that we can grow them honestly over time. With those goals in mind, we will usually be doing right by our customers and ourselves. We will grow wiser over time as to what is simplest in our problem domain, in our programming milieu, and for us as developers. As a result, we ought to be able to give even better answers in the future. -----