Andy Hunt says, "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."

Read this Artima.com interview with Pragmatic Programmers Andy Hunt and Dave Thomas:

http://www.artima.com/intv/metadata.html

Here's another excerpt:

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.

What do you think of Dave and Andy's comments?

*Dave Thomas*: 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.
__________________________________________

I think this opinions is really great, and apply to everyone but not only programmer

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.

I'm not sure that's entirely accurate. In XP estimates are a function of experience, with immediate feedback... In theory you're supposed to draw upon previous experience to make estimates - this story is similar to a current story, so it's worth X development effort. And then, by virtue of tracking estimated vrs. actual, you get quick feedback on how accurate your estimate was.

I don't see Pragmatism as being contrary to Agile (XP) processes. I do see how pragmatic processes could be very helpful to the XP process though. If every programmer on an XP team was pragmatic, I would imagine that they would be able to produce some kick-ass code, and an incredible system...

First, this is my first post on Artima, and I would like to start by saying that this is one of the few fantastic sources of information for software engineers that I know of.
Congratulations Bill.
Regarding the article, a few comments:

1. Regarding metadata and mini-languages: What is the best language to deal, with a specific problem X? Java, C#, C++? Nope, its a language that deals with the concepts of that specific problem, so it would be a language invented on the fly (with some degree of care) that has the basic building blocks for the problem at hand. Of course a good choice of a systems language/platform on where your programs will be finally deployed is still of great convinience.
2. The type of approach on point 1 seems, fortunately to be gaining some momentum, as we start to see XML schemas for handling declaratively lots of problems. I just question if XML, from an elegance and managebility point of view is the best choice (as this is to be handled by humans). I would prefer something less verbose.
3. I don't think that pragmatic programming and XP have to colide on this. I think its possible to have an XP approach where you develop the basic building blocks to be manipulated by an higher-level language. These blocks and the higher languages itself would iterate and be refactored as the projects go on.
4. This is of course not a silver bullet, it just makes life a lot easier (and much more productive) and its surely more pleasent to code near the problem domain than dealing every time with general purpose language excentricities that mean nothing to the problem being solved.
5. People seem to be afraid of learning new languages in general (being domain-specific or general purpose languages). I think this arrises from the fact that lots of people in our industry have not enough conceptual knowledge to see that not that much changes (in a fundamental way) from language to language. For example most people don't understand the difference between static and dinamic typing because they are just used to one language and they were never exposed to an approach to make them see "behind the scenes". Fortunately considering the typical articles on artima I doubt that the typical artima reader fits this view. You can call me elitist, but I think that it should be expected from a software engineer the understading of programming language concepts and not only the concrete knowledge of 1 or 2 languages (coupled with the incapacity to rapidly adapt to change)

Again, congratulations to Bill Venners, for this fantastic site.

[BTW: great site, Bill! Wonderful the calibre of telent you've attracted, too]

I think the point about "experience" is very telling. A lot
of XP is aimed at new programmers (or people programming in new areas they are unfamiliar with). If you don't know what you are doing, you had better not commit to anything prematurely! And in a genuinely new area, that applies to all of us.

For example, on table-driven programming: extracting out such details into a table only makes sense if you know that this view of the problem is correct. A strong hint is if you find you have a bunch of cascading if-else statements *already*. Then, it could make sense to use a table.

Or if you use polymorhpism to get different behaviour
for different contexts... you could convert that to a table, too.

And... maybe you don't have if-else cascade, nor polymorphism, but you can see that you *could* convert it to one of those forms... that is another candidate for table-driven programming.

I've converted to polymorphism a few times... but the resulting code was quite awful, adding a layer of complexity. Too much premature committment to a
particular view of the problem, too. I think tables would be the same - although more flexible in their content, you are still committing to what you think are the invariants.

I can see that if you are programming close to the domain, then your view of the problem probably is going to be correct, and so this commitment is fine. But if you don't have a clear view of the domain (ie defining and understanding the domain is part of the problem), then committing to tables of a particular kind is just adding overhead that (very likely) will have to be thrown out.

I think that these approaches weren't really appropriate to the problems I tried them on. It would be nice to see some concrete examples of where it *is* appropriate.

I get the sense that Andy and Dave have a tremendous amount of experience, and in a number of domains... and so what works for them may not work for others, if they lack this level of domain knowledge and understanding.

The issue is similar to upfront design of modules - unless you understand the problem pretty well already, you really want to avoid committing too much to a particular modularity, and just get one with coding and so maximising your learning about the problem. (Of course it's different if you absolutely have to modularize easrly on, in order to divide up the work).

> 5. People seem to be afraid of learning new languages in
> general (being domain-specific or general purpose
> languages).

Fear can be a factor - but there is another.

It takes a long time to become fluent in a language (and all the associated libraries and tools etc), and unless you are a genuis polyglot, it's hard to maintain that fluency in several languages at once.

Of course, you may still be able to program in many languages - you'll just be much more effective in one of them. To leverage that fluency, you'll try to stay in that language as much as possible [*] - but of course, not more so. Sometimes it's better to switch languages for a particular task, if another language is much more appropriate for that task.

Compare it to human languages. How many languages are can you get by on? And in how many of those languages can you read a newspaper smoothly? If you aren't multilingual, try this instead: use Google to read a news-site from another language...


Cheers,
Brendan
[*] Hey, I've even heard of some people how will write a translator from their home language to some other language, sooner than code in that other language! And it's an effective strategy.

> It takes a long time to become fluent in a language (and
> all the associated libraries and tools etc), and unless
> you are a genuis polyglot, it's hard to maintain that
> fluency in several languages at once.

From the point of view of a domain language you really shouldn't have lots of associated libraries and tools, which is probably 95% of learning a language. Not the language itself (at least for a person with proper computer science trainning).


> Compare it to human languages. How many languages are can
> you get by on? And in how many of those languages can you
> read a newspaper smoothly? If you aren't multilingual, try
> this instead: use Google to read a news-site from another
> language...

I think this is bad example. I think a parallel can be drawn but pointing precesily in another direction:

1. If you know a latin derived language (say french), with very little effort you can be up to speed to read any other latin derived language (spanish, portuguese, italian, ...) to a level much higher than the one offered by google
2. The same is valid for a germanic derived language (*), and probably for any other language family

I think you can replace say latin for imperative and germanic for functional and apply it to computer terms (I know, there is an abyss in between natural and computer languages, but I think the parallel holds).

(*) The exception is english, which although a germanic language has very few similarities to the other germanic languages

BTW, I work in an international organisation and there are people here that are fluent in 7(!) natural languages. Others can speak 5. I content myself with 3 and the ability to read ~7 (which is below average here. Of course, to compensate there are people from english speaking countries which, most of them, only speak english ;-) ).

> [*] Hey, I've even heard of some people how will write a
> translator from their home language to some other
> language, sooner than code in that other language! And
> it's an effective strategy.

Especially when changing language paradigm I think there can be lots of gains. I am currently dealing with a data transformation problem that I hope Prolog will make the solution 2 orders of magnitude smaller in size.

And between C and Perl for text processing... (and I hate perl, but...)