>John,
>
>We all like to use the ol chestnut of 'say your user suddenly demands a global change like a new font. . .'. Let's face it, we usually cover off basics like that very early to avoid it later or, more likely, it ACTUALLY never happens!<

Requests to do things like that happen ALL THE TIME. Especially when it comes to global changes in business rules. In which case, a true business class construct comes in handy! You may not remember some of the requests I'm sure you've had that would have involved mass changes for seemingly trivial problems because you dismissed them out of hand (probably quite rightfully) and forgot about them.

A more likely change of a 'global' nature might be along the lines of:
>a) he's decided to expand and will have a partner who needs same services from same system but separately identifiable; or
>b) They are opening another store on the other end of town and want to control both from the same system; or
>c) The time of day that certain transactions happen has suddenly become of interest.

Yep, those things happen too.

>
>OOP might be helpful with these "problems", but none are a 10-15 minute job!
>
>I guess I could say 'Sorry, I can't do that for you, but I can change the fonts in 10 minutes for you if that'll do instead'.
>

Now wait a sec, Jim. Don't pick on my example with the fonts...it was one of many possible situations. Changes in application design paradigms and products that support those new paradigms DO diversely enhance the ability to create and maintain an application. I guess, by your definition, I would have been equally adept sticking with my old coding environment which was JCL and COBOL ANSI 68 on a 370 with Hollerith card input.


>What I am trying to get at is: just because a tool NOW gives us the ability to do some things that were a pain to do at one time, these are still the very trivial and cannot be used to justify one product over another.
>

NOT trivial!!!! Not at all! See the above paragraph.!