JWColby
jwcolby at colbyconsulting.com
Sun Jan 7 21:15:29 CST 2007
Jim, There are two different ways to view this. By using a framework I can get more done faster, so for the original budget I can give the client more. You are absolutely correct, no "junior level access programmer" is going to come in and pick this up in a couple of weeks. My experience has been though that junior level programmers are brought in to do queries and reports using an existing application. No application of any complexity can be picked up by ANYONE in a few weeks. The framework is a tool. It is similar in concept to Access itself. It allows me, a developer to do things which if I had to do all this stuff from scratch would take years or decades (in the case of Access). I don't make any effort to "change" Access, I just use it. I would not expect any junior level programmer to "change" my framework either. I would just expect them to use it. Mostly it just happens. In fact, when I was in Mexico I hired a non-programmer, a girl who could type and wanted to learn Access. I had her "stamp out" forms for me, just set up the forms, I built the queries, she dragged and dropped the controls out and arranged them. I had a large project I needed to get out, 200 tables. I got 90% of the physical design work done using a smart girl who could use a mouse and type, and could follow a 10 step written instruction on how to do a form. To do it from scratch, build a form, dimension a variable for a clsFrm and pass a pointer to the form in to clsFrm. Voila, things start to happen. That simple. Learn how to pass in the name of a list form to a combo box and voila, the combo starts to respond to the double click event by opening the form. Drop a combo and a text box onto a form, bind the text box to the PK of the data displayed on the form, set the combo's rowsource to display a key piece of data, and voila, the combo can be a record selector and cause the form to move to that record. These are just behaviors that I have added to my classes. Like behaviors of the objects in Access itself, they "just work". All you have to know is what is required to cause the behavior to happen. I have a standing, stated agreement with all of my clients, which is, "if a behavior is generic, it goes in my framework, if it is application specific, it goes in the application". I say that up front. I own the framework. My client gets a limited use license to use the framework, in any application I DEVELOP for them. As I work for them, they pay me for all development, whether it goes in the framework, or in the application. I own the framework. The client gets all of the behaviors paid for by previous clients. They only have to pay for behaviors that have not been previously developed. That is fair enough I think. I walk in the door with (as you put it) a cookie cutter that allows me to do more for them, faster, than they could get with any other developer. I certainly do not force any client to use the framework, but I do advise them that it will cost many times as much to not use it. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Sunday, January 07, 2007 12:25 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Log files Hi John: > I thought you guys might appreciate seeing how I do this. You have created an excellent environment where it is almost a cookie cutter process to build and design applications. Mind you this is not the sort of environment, that after an application has been completed and you have left, the client can now employee some junior Access programmer to do support work on and expect any major progress for a couple of weeks ...and that may be the entire client's expected support budget. ...Which I guess is a good thing. Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com