«

In recent years I've been unable to find anyone willing to pay me an
hourly rate for my fine work writing computer software. Apparently no
company is willing to hire anyone who has been out of work, for fear of
paying even minimum wage and getting somebody nobody else wanted and
now they know it's because they can't get any software working within a
reasonble time (hence for a reasonable amount of wages given hourly
pay). I have been offering to do trial work first, then get paid if
they like my work, but no company is willing to do even that because of
problems getting me covered under their liability insurance policy if
I'm not a legal employee yet I'm on their premises a lot. And of course
Stanford University (*SU*) was the only place that ever allowed me to
work remotely and keep track of my own hours worked, so working off
premises now is not an option. Telecommuting is a fantasy, an urban
legend.

*SU* (where I used to work before the Loma Prieta earthquake absorbed all
their university funding for damage repair, while their president
Donald Kennedy used governent research funds for his personal
pleasures such as yacht and summer home so we lost all our grants as
soon as the 1990-91 fiscal year grants expired, and a recession hit
about the same time so IBM and other companies which had been funding
us until then cut off their funding.)

A while back some people on the net suggested I work for a fixed-price
contract instead of an hourly wage. That way the company can tell me
what they need, and I can do all the work on my own time, and then when
I have something fully working I present it to them and they pay me
that fixed amount, and they don't have to worry I'll bill lots of hours
without getting the job done. But I never did that before, so I had no
idea how much to charge for any given program. I would like to get at
least Federal minimum wage, just as if I had an hourly job, but I have
no idea how many hours a project should cost hence no idea how much
would be a fair asking price.

During the 2005.Spring school term I took a course in distributed java.
One thing the instructor emphasized was writing up "Use Cases", and
agreeing to them with the customer, before starting any of the rest of
the design. After doing this (*UC*) for a few class homework
assignments, it occurred to me that given each Use Case specification,
I might be able to easily brainstorm with my customer (*RC*) and we
could agree to a specific list of methods needed to implement that
single Use Case in a nicely structured manner (*SP*), and I'd write up
that two-level list of use cases with methods of each. From my
experience with the homework assignments, I had an idea how long each
method took to write and unit-test (about one hour), so if I charge a
flat rate of ten dollars per method that would be fair. So putting this
all togethe, as soon as I write up the methods for each Use Case, I
could then immediately state my fixed price for each Use Case, and
hopefully the customer would be pleased at my resonable prices and
agree to the contract.

*UC* (just on my own, the instructor playing the role of "customer"
never had time to really look at my Use Case document much less
discuss it with me)

*RC* (a *real* customer, who actually *wanted* my software, and would
be paying money for it, so he/she would be willing to spend the
time necessary to make sure we were in agreement about what I'd
be implementing)

*SP* (no method that does more than one primary task, rather a bunch of
single-task methods and a bunch of task-controller methods that
merely call the various single-task methods without doing any
significant algorithm themselves)

I have found anyone anywhere around here who wants any software work
done, and all the job ads have required skills or experience I don't
have, making it a shot in the dark to send a resume to any of them, and
precluding getting any fixed-price contracts or even interviews about
such possibilities so-far.

Recently I've been working on a software project that is so large that
I couldn't keep track of it all without breaking it into modules in a
nice organized way. Each module implements all the software for
handling one kind of data, and typically provides what I call a "weak
enumeration" (*WE*), and related software (such as getting a whole list
of elements per some range specification i.e. sub-sequence, or doing
the whole process of constructing a new enumerator and getting one
element if any and discarding the enumeration within a single call,
etc.).

*WE* (instead of one method to say whether there is another element of
the collection available later, which requires look-ahead to make
that determination, the lookahead needing to actually calculate
the new element in a way that changes the state of an inner
enumeration, so the element must be cached or lost forever, and a
second method to actually retrieve the next element of the
collection, which was already cached during the lookahead,
there's just a single method which returns either the next
element if it finds any or an EOF value if it ran off the end
before finding any new element. By the way, what I'm doing in
many cases is having the outer enumeration be a "filter wrapper"
or just a reference wrapper (*RW*) around the inner enumeration,
and in some cases there are several levels of one enumeration
acting as a filter for the next lower enumeration, and shortly
when I'm nearly finished I'll have recursive loops in these
enumeration wrappers)

*RW* (Whereas a "filter enumeration" simply returns the same elements
that the inner enumeration returns, but filtering, i.e. passing
some but nullfiling others, a reference wrapper builds a whole
new kind of enumeration but requires some inner enumeration to
feed it data to process to make that outer enumeration. If you
like the word "continuation" instead of "enumeration" that's
fine. An enumeration is nothing more than a particular kind of
continuation, namely something that successively returns the
elements of some collection, virtual or real, whereas a general
continuation might return something else such as successively
more narrow ranges around a single approximately-computed value.
In my particular application, the dynamic nesting of reference
wrappers will be recursive! I.e. there will be reference loops,
where one large enumeration is defined to include a smaller
enumeration of the same class, possibly going around the
reference loop several times, and possibly branching in a tree
structure of references, until the leaves of that kind of
enumeration get small enough to use a more basic class of
enumeration instead, finally bottoming the recursion).

Now that I've broken the program (so-far) into separate files for each
class of data being processed and the one or more enumerations dealing
with that kind of data, I can step back for a moment and see what I
have so-far, sorted by size:

8 -rw------- 1 rem user 6591 Jul 8 18:27 2005-7-ranpri-gpsq.lisp
12 -rw------- 1 rem user 11310 Jul 8 18:31 2005-7-ranpri-gp.lisp
14 -rw------- 1 rem user 13319 Jul 7 18:10 2005-7-ranpri-mf2.lisp
16 -rw------- 1 rem user 14910 Jul 7 20:43 2005-7-mbbt.lisp
16 -rw------- 1 rem user 15653 Jul 8 18:35 2005-7-ranpri-mf1.lisp

(Those sizes include: code, per-method and per-enumeration
documentation, and unit-test rigs.)

I notice the modules range from 6591 to 15653 bytes, a factor of
2.3[7..8] (*II*), which is not very wide. After seeing this, it occurs
that I could offer a fixed price per class that I write, estimating
near the high end of 15k bytes, and if it turns out that the class
wasn't as hard as I estimated so the file didn't turn out as large as I
estimated, I could offer the customer two choices:
- Get a discount from the originally quoted price.
- Think of additional features to include in the class or in any other
class within the same billing cycle, covered under the original
price quote.

*II* (Hmm, as long as I keep talking about my proposals for Interval
Arithmetic, and my proposed notation to represent known digits
and range of unknown digits for output, I might as well use the
same notation whenever I post an approximate real-number value in
a newsgroup, and here (above) is my first such usage!)

So why am I posting this? Please anybody who has ever billed software
via fixed-price contracts, if you produced Java classes or Lisp modules
of approximately that size range I cited above, how much did you charge
for each such appx.-fixed-size class/module? I need your advice how
much I should state as my going price for fully working code with
unit-test and software documentation included. What's the going rate
for professional fixed-price software contracts of approximately the
size cited above.

P.S. If anybody has looked at the filenames listed above, and it
whetted your curiosity to know what big project I'm working on, just
ask and I'll tell. But if you read what I was posting about this topic
in sci.math a few weeks, you can probably guess, and I encourage to
post a followup making your guess public.

Robert Maas, see http://tinyurl.com/uh3t wrote:

> In recent years I've been unable to find anyone willing to pay me...

We have been around this bush. What open source projects have you started
patching since I suggested it?

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

On Fri, 08 Jul 2005 21:31:26 -0700, (Robert Maas,
see http://tinyurl.com/uh3t) wrote or quoted :

> I would like to get at
>least Federal minimum wage, just as if I had an hourly job, but I have
>no idea how many hours a project should cost hence no idea how much
>would be a fair asking price.

There are websites where people offer contracts and bid on them.
check these out to get an idea the going rates.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Nobody nowhere on the planet is going to pay for software based on the
number of bytes in the source files! Software is not like potatos, you
don't get more money for providing more. Besides, most of the time,
the better you understand the problem domain and the higher your skill
and experience, the more you achieve with less.

If you are going to write software for a fixed price contract, the
only way to determine the right price is to have an accurate idea of
how long it will take you to do the work. The only way you can know
this is through a combination of knowledge/understanding regarding the
problem area and an accurate and honest estimate of your level of
productivity. It is also very important to have a clear and agreed
scope which not only includes specific deliverables, but also what is
not to be delivered and what the costs would be for changing the
scope.

To work out how much to charge for some software you write, you need
to know -

1. How many hours it will take you to complete the job. A useful trick
is to make your estimate and then multiply it by pi.
This often gives a more accurate figure once unexpected factors
come into play.

2. Determine how much you want to earn a year

3. Work out how many hours you can work a year. A useful formula is

(52 - holidays) * workdays_in_week * hours_in_workday = year_hours

Note that this is meant to be hours you can charge for, so you
cannot have 7 wordays in a week because there are lots of things
you need to do which you cannot charge for (chase down work,
marketing, taxes, general office admin etc). I've found that if
you are doing long term type contracts, you can generally work 3
days out of every 7, but if your doing short term contracts, you
need to do more admin and therefore can only work 2 days per
week. Its also important to put a real number on the hours you are
prepared to work in a day - don't put 16, put 8 or maybe 9. Note
that I'm assuming a 5 day working week with two day weekends.

4. Calculate your hourly rate by dividing your year_hours into your
targeted income for the year. Then multiple that rate by the number
of hours it will take to do the job and you have a figure you
should charge. Simple.


--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!

(Robert Maas, see http://tinyurl.com/uh3t) writes:
> A while back some people on the net suggested I work for a fixed-price
> contract instead of an hourly wage. That way the company can tell me
> what they need, and I can do all the work on my own time, and then when
> I have something fully working I present it to them and they pay me
> that fixed amount, and they don't have to worry I'll bill lots of hours
> without getting the job done. But I never did that before, so I had no
> idea how much to charge for any given program. I would like to get at
> least Federal minimum wage, just as if I had an hourly job, but I have
> no idea how many hours a project should cost hence no idea how much
> would be a fair asking price.

This is rather easy.

If the target business process earns the corporation X dollar/year
without your software, but earns X+Y dollar/year with your software,
then you can sell them at a price that depends on the time to ROI they
will accept:

P/Y = TTROI

P = TTROI * Y

For example, if their business practice on investing is to expect a
TTROI of 0.25 year, and your software will allow them to earn 1 more
dollar/year/customer and they have 100,000 customers, that is, your
software will earn them 100,000 more dollar/year, then you can quote
it for P = 0.25*100,000 = $25,000.

Note the software might allow them either to increase their income,
or to decrease their costs; it doesn't matter, what counts is that it
increases their benefice.

Also it's possible that the software allow them only to increase the
number of customer even at the cost of a decreased earned
$/year/customer: it's better to have 100,000 customers/year earning $1
each, than only $10,000 customers/year earning $2 each. Your Y will
still be positive: $100,000 - $20,000 = $80,000.


It might be profitable to target businesses that accept longer TTROI,
or businesses with a greater number of customers (or with a greater
potential increase in customer number)
or software that give greater improvments in productivity ($/year/customer),
or both.

--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.

Roedy Green wrote:
> On Fri, 08 Jul 2005 21:31:26 -0700, (Robert Maas,
> see http://tinyurl.com/uh3t) wrote or quoted :
>
>> I would like to get at
>> least Federal minimum wage, just as if I had an hourly job, but I have
>> no idea how many hours a project should cost hence no idea how much
>> would be a fair asking price.
>
> There are websites where people offer contracts and bid on them.
> check these out to get an idea the going rates.
>
Example would be http://www.getafreelancer.com

--


Thanks in Advance...
IchBin, Pocono Lake, Pa, USA
__________________________________________________ ________________________

' If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor, Regular Guy (1952-)

Pascal Bourguignon wrote:
> For example, if their business practice on investing is to expect a
> TTROI of 0.25 year, and your software will allow them to earn 1 more
> dollar/year/customer and they have 100,000 customers, that is, your
> software will earn them 100,000 more dollar/year, then you can quote
> it for P = 0.25*100,000 = $25,000.

So what would be the rationale for charging double for the same product
simply because they are willing to wait six months rather than three
for ROI?

Robert Maas, see http://tinyurl.com/uh3t writes:

> Telecommuting is a fantasy, an urban legend.

Hmmm...apparently I, and several folks I know, are living, or more
correctly: working, in a fantasy world.

Cool! (-:

--
|_ CJSonnack <> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

"jonathon" <> writes:

> Pascal Bourguignon wrote:
>> For example, if their business practice on investing is to expect a
>> TTROI of 0.25 year, and your software will allow them to earn 1 more
>> dollar/year/customer and they have 100,000 customers, that is, your
>> software will earn them 100,000 more dollar/year, then you can quote
>> it for P = 0.25*100,000 = $25,000.
>
> So what would be the rationale for charging double for the same product
> simply because they are willing to wait six months rather than three
> for ROI?

Who told anything about reason? It's psychology. You approach the
"decider" with this argument: "Hey, with my product, in six months
you'll be earning twice the dollars you earn now.". While you don't
have a competitor bidding a TTROI of three months, you don't need to
bid less. If you good at it (you approach the decider in the right
context with the right adornments), you can even bid a TTROI of one
year.


--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush

jonathon <> wrote:

> Pascal Bourguignon wrote:
> > For example, if their business practice on investing is to expect a
> > TTROI of 0.25 year, and your software will allow them to earn 1 more
> > dollar/year/customer and they have 100,000 customers, that is, your
> > software will earn them 100,000 more dollar/year, then you can quote
> > it for P = 0.25*100,000 = $25,000.
>
> So what would be the rationale for charging double for the same product
> simply because they are willing to wait six months rather than three
> for ROI?

That they will pay for it. You don't need to have a rationale -- you
figure out what term ROI they will accept and then price your product
accordingly. If other people are out there who can and will do the same
job for a lot less, then you can't use that idea. But if you are the
only one who is calling on them (or whom they know) who can implement
the idea in question, then you should be able to get whatever the cost
savings merit from an investment standpoint.

There's a problem with Pascal's analysis though -- it doesn't allow for
uncertainty, and uncertainty is a very hard sell. You can do the math
to allow for it, but if the person you are talking to doesn't understand
things like Expected value, utility of money and other speculation (or
gambling) principles, they are going to tend to be much more risk averse
than they "should" be depending on the decision maker's personality.



Michael