-----Original Message-----
From: Nick Tornow[mailto:ntornow@sheergeniussoftware.com]
Sent: Thursday, March 27, 2003 11:43 AM
To:internal@sheergeniussoftware.com
Subject: Re: If you didn't read this already

I'm in a nit-picking mood lately with people over-simplifying the software process, so while I think I agree with both Andy and Dave I found this interview to be a bit muddled and am going to make some comments for your optional perusal:

Page 1: While their point here is good, that configuration information can be seperated from the logic, I think they are dodging some issues.  For instance, each field that you make configurable requires several considerations, none of which are discussed: 

1) each configuration field multiplies the possible configurations of the system by the set of possible values for thatfield.  This is an occassionally overlooked problem at development time that can make testing and error tracking more difficult

2) one must consider validation of configuration fields

3) one should consider security of configuration fields

4) one should consider whether the configuration field must be documented

5) changes to configuration fields have implications for software upgrades

Page 2: "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. " - I pretty much agree with this discussion

Page 3: Again they dodge many issues with the point of the value of creating a "mini-language".  The points are generally good but should be tempered by counter examples:

1) "When there's one change in the real world, you want to be able to make only one change in the code. By setting up an environment that includes a dedicated domain language, you come much closer to that goal" - modern programming languages provide many abstractions to allow higher level work, such as objects and methods.  Though I think the first point is generally valid, the second is inaccurate.

2) a mini-language must be coded, tested, and maintained

3) new developers must learn the mini language, but they sometimes won't at first and therefore there may be many mistakes made

4) the mini-language will not have the full expressive power of the real language and will therefore sometimes need extension

5) once the extensions to the mini-language become substantial, there is little argument for using the mini-language at all

I am not attempting to refute the idea of a"mini-language" just saying the interview glosses over the core issues.  Unfortuantely, this seems like an all-to-common trait of many software articles I have read lately.  The interview format in which the interviewer does not act as an antagonizer only makes it worse, imho.

-Nick

----- Original Message -----

From: Tully Edson

To: internal@sheergeniussoftware.com

Sent: Thursday, March 27, 2003 9:30 AM

Subject: If you didn't readthis already

Put Abstractions in Code, Details in Metadata

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

--Tully