Sponsored Link •
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.