Stuart McLachlan
stuart at lexacorp.com.pg
Tue Jan 4 14:26:18 CST 2011
I would strongly advise against the "full-time" bit The problem is that you lose contact with and availablility to your other clients if you are working full time for one client for too long. At the end of the contract period you have to start to either re-built your customer base again or put yourself in the hands of recruiting agents for subsequent contracts.. I made that mistake once a few year ago - never again! -- Stuart On 4 Jan 2011 at 7:21, Dan Waters wrote: > Hi Jim, > > I've been thinking about offering potential clients that I work as a > direct full-time employee for 1 - 2 years while I build their system. > Then I'd move on to another company, but perhaps still provide some > support to the earlier ones. It's seems like it's actually easier for > a company to hire a direct employee than it is to pay out cash to a > contract developer. > > How are you approaching your clients about being on their payroll? > > Thanks! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim > Lawrence Sent: Monday, January 03, 2011 9:32 PM To: 'Access Developers > discussion and problem solving' Subject: Re: [AccessD] Move to C# - > last post > > In the long run it is definitely paying off. > > I have been in discussions with clients about putting me on payroll if > they want their system upgraded to .Net. The alternative of a 10 to > 15K entrance fee, with much more to come, scares off many but it seems > many are realizing that they too have no choice especially the ones > who have been already badly burned. ;-) > > Jim > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Monday, January 03, 2011 3:40 PM To: Access Developers > discussion and problem solving Subject: [AccessD] Move to C# - last > post > > Jim, > > > You noted three excellent classes you created for your client. If > you > were to accurately the > hours required to get these classes fully tested and operational; what > would that be? This is just a diabolic curiosity but do not hesitate > to put an appropriate dollar value to your time with this development. > ;-) > > I cannot accurately estimate the actual time simply because I did it > piecemeal, and in a waterfall kind of way. IOW I started with > existing SQL stored procedures (about 50 or so). I wrote code that > simply encapsulated calls to those plus logging. > > I then went back and wrote classes that encapsulated those > encapsulated stored procedures (supervisors if you will). > > I then learned new things and... I went from a simple status text box > on a form to a status list class which I now use throughout the system > to report status for any process that needs to do so... and nLog, > and... > > I started with single threaded, then moved to multi-threaded, breaking > it out etc etc. > > How long would it take me to write the same from scratch knowing what > I know now? > > Maybe 200 hours, and I charge $60 / hour to this client. And while > that sounds like a lot of time and money (and it is) it automates a > very complex process that moves me from 16-24 man hours per list (of > my time) to zero man hours (of my time). And I have a half dozen > lists, and they each need to be processed monthly. And my orders pass > through this process as well. > > So the program now saves me well over 100 man hours a month of my > time. > > My server still takes man days to complete the work but it no longer > requires me typing on the keyboard for each step. > > This export / process / import process is central to the business for > this client. I started learning C# in Sept 2009, and within two > months started building the first iteration of this automation. By > January I was successfully processing these stored procedures and > logging results. However it was in a sequential fashion, start one and > go until it was complete. Since any given table can be a couple of > hundred thousand up to a hundred million records, processing a single > table could take days of processing time. Each two million record > chunk takes about one hour to process. > And I had to manually start each table that needed processing. > > Now I have a record in a supervisor table that contains the database > name / view name of the data to process and the date to start the > process. The asynchronous process can read that supervisor record and > decide whether it is time to process. When it is, the program can do > the complete thing without intervention. When it is finished, if it > is a data database (master data) it will automatically copy the > supervisor record into a new record and set the date out 30 days so > that it just automatically reprocesses every month. If it is an order > supervisor record, it just processes once and is done. > > I have been through about three distinct refactorings to get from the > first fairly clumsy stab at this to where I am now. I have learned a > ton along the way. And each refactoring paid for itself directly as > each version took less and less of my time. > > John W. Colby > www.ColbyConsulting.com > > On 1/3/2011 5:03 PM, Jim Lawrence wrote: > > Hi John: > > > > I agree with you fully. I have no intension of wasting any more time > > with > MS > > Access...it is simply a dead and dying platform. :-( > > > > Getting up to speed will take a long while but I know that can not > > be helped. Any adventure into this area will cost myself dearly in > > time and > my > > client's dearly in money but that can not be helped. > > > > You noted three excellent classes you created for your client. If > > you were to acurrately the hours required to get these classes fully > > tested and operational; what would that be? This is just a diabolic > > curiousity but do not hestitate to put an appropriate dollar value > > to your time with this development. ;-) > > > > Jim > -- > 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 > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >