John W. Colby
jwcolby at colbyconsulting.com
Wed Mar 24 19:01:34 CST 2004
Yep, yep and yep. My clientele is about development time which is why I do what I do. Unfortunately I have never had a "here's a half million, take your time" client. My standard agreement with all of my clients is that if they hire me they get a license to use my framework. My framework drops my development time radically simply because I don't program the same thing over and over and over... Furthermore my agreement states that if it is application specific, it goes in the app; if it is generic, I get to decide whether to place it in the framework. I OWN the framework. The client gets the benefit (for free) of all the development that has gone before and pays for all the development that comes on their shift. I add new stuff to the framework almost every job, paid for by the client in all cases. Thus month after month, year after year the framework gets more and more advanced, new ideas, new behaviors. Each client inherits more stuff and pays for a "higher level" of development simply because that's what is left to do. As time goes on, most of the development becomes application specific, but again, if I develop something that I "coulda used on that other job" I retain the right to keep that code and place it in the framework for the future (or my other clients already using the framework). John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller Sent: Wednesday, March 24, 2004 8:10 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Framework Discussion - Another poll I am, but admittedly with reservations. Back in the dinosaur age I wrote a lot of stuff vaguely similar, and subsequently discarded for performance reasons. That was back when all you could count on was 640K or maybe 1MB of RAM. But perhaps the analysis still obtains. As I see it, there are two poles: 1. Write everything O-O and have the framework figure out what to do at run-time. 2. Regen the entire app so nothing has to be figured out at run-time and everything will therefore perform much more quickly. I'm not yet sold either way. Or perhaps more accurately, I am sold one way or the other depending upon the app's requirements. Given 1000 users, development time is trivial compared to execution time. Given 10 users, development time is much more significant. IMO, if performance is paramount, data-driven doesn't cut it. But there are lots of apps in which performance is not paramount, and in that case data-driven may be the right way to go. I wrote a lib a long time ago which was based on data-driven tech. Turned out the California Red Cross was one of our biggest customers. In their context, the performance-hit for data-driven was a serious problem. Heart-pacers were at stake, and various other machines. Any possible performance-hit had to die, else some patient might. 120 users to start, it later got a lot bigger; seconds mattered big time: every fraction of every second mattered big-time. Not to say every app is like that. Just to say that I have learned the hard way that when performance is paramount, data-driven loses. When it is not paramount, data-driven wins pretty much hands down. My $.02. Arthur -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, March 24, 2004 1:56 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Framework Discussion - Another poll Hi John I do. /gustav > I need to take another poll. Would everyone following the discussion > please raise their hands. -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com