Knowing What Will Change

Bill Venners: That sounds nice in theory, but how do I know which things to make
configurable? How do I know which things are likely to change?

Andy Hunt: I think knowing what to make configurable is largely a matter of
experience. Some of it is just common sense, but most of it is experience. In a couple of
instances I have decided off the top of my head to stick a parameter into a properties file, to
help make the system soft and flexible. But when I talked to the user, I learned that the
parameter hadn't changed in 30 years. A parameter like that isn't likely to change in the
future, so it probably belongs in the code.

Dave Thomas: That is crucial. I think another difference between us and the XP
folks is that we value experience. We think your experience is a key component of your
everyday work. It is perfectly valid to look at your experience and say, "The last time I did
this I got bitten by this particular field changing 17 times, so this time I'm going to abstract
it out into metadata."

You have to accept the fact that you're not going to get it right the first time. And you're
not going to get it perfectly right the second or third time. You'll never get it perfectly right,
but along the way you can get better and better . To do that, you have to discipline yourself
to apply a reflective process to what you do.

Bill Venners: What do you mean by reflective process?

Dave Thomas: You always have to look back at what you did and ask, "How did I
do that? Could I have done it better? Did I have to do it at all?" Get into the habit of doing
that with everything you do. That way, you're consciously forcing yourself to reevaluate the
way you do things.

In the 70s, there was an "inner tennis" craze. The tennis coach would put a chair in the middle of the court.
You would swing the racquet and fire balls over the net towards the chair. You didn't aim for the chair.
You just hit the ball and noticed whether the ball landed to the left, right, in front or behind the chair.
Eventually the feedback mechanism involved would teach you that when you do this, the ball goes over
there. When you do this, the ball goes over here.

Andy Hunt: So the chair was just providing a reference point.

Dave Thomas: Exactly. And it's the same with a project. If you give yourself
constant feedback, then gradually you'll get better at doing what you
do. That's absolutely critical, but most people don't do that. They rush onto the next project,
without going back and thinking how they did this last one. Without that feedback, you're
never going to improve.

Andy Hunt: Another point is that we hear a lot about
agile methodologies these days, but not a lot about writing agile code. If you want to be
able to keep up with rapid changes on a project, however, you have to make the code agile. You have
to be able to make changes quickly. The XP folks say the way to do that is via refactoring.
They recommend you always keep the code tidy and well factored enough that you can make
needed changes fairly quickly. You can take the XP approach of refactoring the code, but if
pull details out of the code into metadata, you can make changes without even having to touch the code.

In addition, with metadata you have the added benefit that you can make changes out in the field to a system that's already
been deployed. If a customer calls and tells you their MP3 player isn't working, you may be
able to tell them to switch a parameter in a property file. The MP3 player will use a
different decoder and algorithm and get around the bug. So the more metadata you have, the
more flexibility you have. And flexibility translates into being agile.

Dave Thomas: In addition, once you start planning your code this way, you find
that the discipline actually improves the design of the code.

Bill Venners: The discipline of separating abstraction and details?

Dave Thomas: Yes, once you adopt a discipline of separating the
abstraction and the data that abstraction is working on,
your code starts being structured in a far tidier way. Your code tends to
be decoupled and orthogonal. The discipline is to structure your code in such a way
that you can drive it from metadata. By doing that you're guaranteed to have
nice, self-contained, clean chunks of functionality that you can assemble in different ways.