Hey Tom,
Yes, I know there is a difference between a tool and a crutch. If you are using a tool and it is working for you I am all for it. What is a tool for some people, can be a crutch for others. I only used the term "bag of tricks" to differentiate between a group of well tested modules/libraries that handle core and often tedious actions that people sometimes call a framework from a true framework like MM for Foxpro and I am sure MM for .NET.

Wether you use a framework or not you must have a quality design which includes a set of well rounded company IT standards. I don't have a problem with frameworks. I was answering a question regarding them.

What I attempted to say rather poorly, was, Frameworks have there place in our total toolbox. I have worked with MM in fox and it was ok. I have worked without a real framework more often than not.

Joe.



>Joe;
>
>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.
>
>1. Uniform and consistent methodology.
>
>
>2. You have a professional team and bulletin board to ask questions and you are not on your own.
>
>
>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.
>
>
>4. Using a framework will allow you to be more competitive.
>
>
>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.
>
>6. While a company may allow “tricks” to be used, I much rather use a proven and acceptable framework.
>
>
>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.
>
>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.
>
>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”.
>
>Tom
>
>
>>>I'm really curious about this, and I have been for a while. So I hope you don't take it wrong.
>>[snip]
>>
>>Hi Gang,
>> We also have to remember that not all developers are developers. Some are maintainers, minor tweekers, and code keepers. Second handers so to speak. While they may be wonderful people undeserving of de-edification, these people typicaly cannot and do not create a project from conception without enormous and highly personal support. I have had the proverbial origional I must write every line of code that goes out kind of developer working for me. (I even used to be one.) I have also had developers MUCH smarter and experienced than myself employing me, working with, and for me that helped me understand several languages well enough that I learned the value of a Bag of tricks type framework.
>> If you have a great junior developer and you need them to do foo which includes an enterprise impacting event. Having them call an assembly or hand-rolled function that holds the enterprises hand is by far safer than saying go get it tiger. Now I always hope, that same person will choose to step through the hand holding code on their own, read the comments and ask questions. But not all will. I know the ideal, but, I also know reality. I think a central bag of usefull source controled and closely monitored tricks is more valueable than a real framework layered ontop of a language. I guess that you could have a framework function called DoAllMyWorkForMeAndIDontWantOrCareToKnowAnythingAboutHow() and that function will call functions calling functions calling functions. Much like an end user doubleclicking an executable...
>>
>> What I mean is the people actually writing the framework are the developers. The people who can only code using that framework are your second handers. If that fits your corporate structure, Cool. But I hate to hear on Dec 21st; "I dont know thats TJ's code. I don't know how he did it. He won't be back till January" I would like my whole team to be able to grab any bull by the horns and run with it because thay all know the language to an extent were thay can make unsupervised progress using help, online forums, other team members, books and especially their own facilities. Now don't read this too harshly, I know I am far from ideal myself and I work all the time to get more knowledge. I have used the ccode from no less than 20 UT people in the past and That code has at times made it into a formal; bag of tricks. :) Other times it solved a unique (for me). I know the ideal, but, I also know reality.
>>
>>Truly Sorry for rambling on, I think this is a chatter topic too.