I have a problem with "per program" rates, in some circumstances:

  If you hit a job like one I did, where the customer plays both the
"pointy-haired boss from hell" -and- "the marketing droid from hell"
roles, where the feature set you have to implement isn't cast in stone
but rather in sand, and where each thing you code, results in more new
features being thrown into "the new (daily) spec that's running away
faster than you can code" <tm>;

  Then, you want to quote an HOURLY rate <G>

  (This was a Windows 3.x embedded system controller comms program which
started off dying at the drop of a hair, ANY hair, ended up pretty
stable - if only I'd been paid for all my work on that beast!)

  Per program, I can see if you are good at estimating, know the current
state of the code (do NOT, please please please, take the clients' word
for this!), and have both a spec written in corundum and a good
contract.

  If you're not good at estimating hours, maybe hire someone who is <G>

  Knowing your strengths and weaknesses is a good idea if you're doing
contracting.

  Mark

Holger Morgen wrote:
>
> Hi -
>
> How about per program?
>
> /holger
>
> > ----------
> > From:         Quentin[SMTP:qsc@ICON.CO.ZA]
> > <snipped>
> > I would like to know how PICsters charge for PIC programming. Do you
> > work on time spend or do you charge per line?
> >
> > I see it this way:
> > If you work on time, you can get involved in a program that is
> > relatively small, but requires a lot of time to configure. Example is a
> > complex timer program where you spend a lot of time configuring timer
> > parameters etc.
> > OTOH:
> > If you work on charge per line, you can get a program that is fairly
> > long but can be written quickly. Example is bit manipulation where you
> > already have a library of frequently used stuff (multiplication, etc.).
> >
> > Any thoughts?
> >
> > Thanks
> > Quentin
> >