>I know what it takes to be a success as a programmer and how to be successful as a company. When VFP 3.0 Beta came out I spent a lot of time creating my own framework. Then I went to Codebook (flash road show), MEI, VFE, and VMP for training. I know more than the basics but rely upon a professional framework for a number of reasons.


I just love messages that start off like that. Thanks for telling all of us that you are a "success" as a programmer and how to be a "successful" company. I'm really sure that adds weight to your opinion.

>
>1. Uniform and consistent methodology.

If you develop your own, not only can it be uniform and consistent, but it can be your OWN methodology and be consistent in any way you like!

>
>2. You have a professional team and bulletin board to ask questions and you are not on your own.

True, you can ask a lot of questions to others. But if you wrote your own, you would probably understand that problem and be able to fix it without asking any questions.

>
>3. A professional team is addressing bugs as well as updated features while you write code to satisfy client needs, make a profit and deliver a reliable product on time.

Well, i agree. I love a professional team doing my bug fixing for me. But, just because you have your own framework doesn't mean you can't deliver on time?

>
>4. Using a framework will allow you to be more competitive.
>

Ok.. Uh.. What is your basis for this assumption??

>
>5. Developing your own framework detracts from your companies profits. You might get the client to pay for your development time but that is not cost effective. It can also give your organization the reputation of “being more expensive” then the competition.

If you are going to be using it for one large set of applications, or use it for all of your applications then it might not be a waste of time. If you can keep the developers, who built your framework and they built it well. You will have a competitive advantage and flexibilty that is difficult to obtain w/ a commerical framework.

>
>6. While a company may allow “tricks” to be used, I much rather use a proven and acceptable framework.
>

I'm not talking about 4 scripts laying around in a file, i'm talking about developing your OWN framework. That is proven and acceptable!
>


>Jumping through hoops and bandaged code in a house of chaos is an environment I dislike working in. I can assure you that I have worked in such places. Management runs the show – it does not mean that they have any concept of what they are doing.
>

Whether it is a framework you developed, or part of a application, hoops and bandaged code shouldn't PROBABLY be part of your application. So it doesn't matter if it is in the framework or other code.

>From the programmers perspective to be successful means standardizing how your company does things. I have worked in environments where no standards were used. Those companies are out of business. A framework allows a corporate standard to be implemented. I view frameworks and those that use them in a different light then you have expressed.
>

?? Didn't you read the earlier posts? Or All of this thread? That is the point of writing your OWN framework. Your own way to standardize. I'm not talkin about each individual developer, i'm talking about the company as a whole.

>Regardless of the economy I like to have an edge on what I do. I do know guys who would never use a framework. They charge much more than I do and I get repeat customers while they do not. I deliver on time while they do not.
>
>Our experience is different. The last thing I want to see in a multi developer environment is allowing each programmer and outside consultant to “do whatever they want”.
>

Ok.. I think you didn't read it the thread huh? Because that wasn't what we were saying about frameworks. Allowing all your programmers to "do whatever they want".

The question or chatter topic was the valuable experience expertised and flexibilty of developing your own framework for your company. IMHO is has more advantages then purchasing someone elses.

Morgan