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.
-----