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

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

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.