Dan Waters
df.waters at comcast.net
Wed Jan 5 10:20:51 CST 2011
Hi Jim,
Your Type 2 is what I currently use - pretty closely. The differences are
that I charge a user license fee (it's a self contained system of which I
own the Library mdb), and I ask for fixed prices after installation - never
a problem with that. I'm very strict on scope creep - we'll get the amount
agreed to before I start (and I have had to say just say no).
The problem for me is that even though I charge a fairly high hourly rate,
my total income is probably half or less what it could be if I went back to
being a Quality Manager at a manufacturing company, or being a Business
Analyst somewhere. But I like what I do now. So, if I could do what I
like, and make twice what I make now, that might be worth being back in the
corporate environment.
My plan is to continue supporting my current 4 long-term customers. But,
one of them wants their system converted to .Net/Sql Server so that outside
users have good access. This will take a few months, at least. After that,
with my new skill as a .Net developer, I'm hoping I can get more paid work.
Either being independent, or doing the same work in a medium sized company
not too far from home.
Thanks!
Dan
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Tuesday, January 04, 2011 8:42 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Move to C# - last post
Hi Dan:
Contract type 1: A set contract is usually a problematic thing. The best you
can do is divide the contract up into separate segments and when each
milestone is reached the client pays up. This always makes the assumption
that, you as the programmer, are going to have a fully function piece of
code at the end of this contract. Usually the last payment is held for a
time until the client is satisfied. This can be dangerous as it is a grey
area where scope creep and the ever present danger of more bugs could
showing up. In the worse case scenarios it ends up with you being out your
last payment, the client upset, feeling there is so much you should and
could be doing to reach their absolute vision...all at no more additional
cost.
Contract type 2: The type of contracts that I usually go for is the
insurance type contracts. This is where a major portion of the development
and payments are made at the start, but a monthly retainer (open ended) is
added at the end of the building phase. In this scenario, the client is
charged a fixed rate, per month and you fix all those little bugs that pop
up as well as add all those items from the out-of scope-project-wish-list.
Sometimes these extended contracts can last from 6 months to as long as 20
years. If this works out well you spend little time at the clients, they
make small continuous payments, they know they are covered and it can work
out to be a very long term friendly relationship.
Contract type 3: The final type of contract tends to be of a size and
complexity that you will have to dedicate a major portion of time and effort
towards completion. It is sort of like a mix of contract type 1 and 2. The
potential customer knows it is going to be an expensive project and you know
it is going to be very time consuming. You can at this point propose a 6
month to a year full-time (employee type) contract. The client provides the
desks and equipment and you provide your services. This way there is not a
huge outlay towards a project and you have time to feel out what the client
really wants and needs and not have to end up making these jumps in faith in
what a sentence of paragraph really means. The project tends to evolve in a
better way.
Now how do you convince your client to agree to this or other type of
contract? Well, just know all the scenarios really well and be able to
present them... I bet when you became a programmer you did not realize that
half your skills sets were going to have be standing up in front of clients
making presentations and selling like a used car salesman.
Jim
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Tuesday, January 04, 2011 5:22 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Move to C# - last post
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
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com