>Excuse me, Jess, but I can't help but point out that if you have a commercial quality framework, then you have the following benefits:
>- Commercial quality documentation
>- Extensive field testing by all sorts of people
>- Ease of new developer orientation
>- Good probability of new developer familiarity at the outset
>- Peer support and sometimes extensions galore
>
>Virtually nobody uses frameworks without changing them. You are right that Frameworks are a great starting points for beginners. But I find your advice that folks should go into lone-ranger mode and develop in-house frameworks to be both silly (bordering on asinine) and unsubstantiated with anything other than anecdotal evidence of benefits you alone may see.
>
>Every shop I've seen (I've been on-site at nearly a fifty VFP shops) has some degree of NIH (Not Invented Here) syndrome, and for the most part this is not always a good thing.
>
>I'd like to refer you to a great new book called Designing Hard Software by Douglas W. Bennett ISBN: 0133046192. He's got a couple of very interesting slants that I recommend you investigate. Here's aquick summary of his message:
>
>There are 2 types of requirements: "Run-time" requirements, which matter most to end users and their sponsors, that define the services provided by the system, and "build-time" requirements which matter most to developers and their sponsors, which define how a system is to be built, evolved, extended, and maintained.
>
>Since Use Cases support run-time requirements, something new called "Change Cases" should support build-time development. Change cases are possible future system changes, things like what happens when a new actor with a different usage pattern is introduced, or what happens when we change the database from say local to remote, or if a stand-alone demo and training version is required in the future, or if the system is adapted to other product lines, or locales, and so on.
>
>The system architecture thus should reflect both build-time and run-time requirements and furthermore the run-time requirements are subordinate to build-time requirements when evaluating an architecture. Whyso? Because run-time requirements rarely if ever determine or even constrain an architecture. It's the build-time requirements that are more determinant of the quality of an architecture. This is heady stuff, and on balance I quite agree with Bennett.
>
>In other words, to paraphrase, the quality of a framework has little to do with its ability to meet end-user (run-time) requirements and everything to do with meeting developer (build-time) requirements.
>
>All this to say, in a roundabout way, that unless you have a handle on the system's change cases one cannot recommend any framework over another, much less recommend a go-it-alone lone-ranger approach based on anectdotal evidence that this has worked for you in your situation. IMO, a lone-ranger strategy is an optipon open only to experts, and even then it is rarely recommendable.
>
>The last time I personally went on a development flyer was 1990. I've been brought-in to consult on salvaging many lone-ranger situations since then, and I have one general recommendation: when in doubt, definitely don't. It's prohibitively expensive, time consuming, and risky.

Hi Steven,

Thank you for your constructive comments!

As I have said, I am not absolutely against frameworks. Since The Entire Foxpro Community considered you as one of the Most Outstanding, Brilliant, and one of the Most Respected Programmer, I would like to ask you a simple question:

Do you think you are at your level now if you just work if not depend on Frameworks and not concentrated on knowing the Deepest ‘Things’ of Foxpro or any language you are using? Or, did you start Programming using Frameworks?

Just to emphasize my point, IMHO, using frameworks and confined into it (not all) is more on fasterrrrr $ thing (savings and earnings). Using them really offers a lot of advantages if developing an End-User application. But to maximize the potential of a serious programmer/developer (i.e. knowing the in and outs of VFP Language, its intricacies, etc.) in a long term basis, it helps but a little, because you have to re-study everything until such a time found yourself backed again to BASICS. It is easy for the readers to memorize good AXIOMS written in English but the person, who wrote it, started from the English BASICS.

Thank you