Programming partnership wanted

Merrill Oveson moveson at gmail.com
Tue Mar 29 16:41:15 MST 2005


Doing projects like this is a lot like taking your car to the mechanic.
The mechanic will give you an estimate - only.
Why? Because too often he gets in there and encounters problems he
couldn't have anticipated.  Rusted bolts that won't easily come off,
other parts that are also broken, etc.

As programmers we're the mechanics, the best we can do is give an estimate.
And the estimate is based on certain assumptions.

Consumers hate that - both when dealing with auto mechanics and programming.
If programmers and auto mechanics were forced to give a set price,
instead of charge an hourly rate, they'd have to multiple their
estimates by 3 - and more often then not they'd still end up working
for peanuts.

Trust me, I've made this mistake more than once.

Common rule of business:
It will cost 3 times what you expect.
It will take 3 times as long as you expect.
It will only generate 1/3 the revenue you expect.

VC types will often factor in these rules as they evaluate potential
investments.




On Tue, 29 Mar 2005 14:39:32 -0700, Sasha Pachev <sasha at surveyz.com> wrote:
> > My web design company seems to have a problem finding programmers with the
> >following traits:
> 
> > 1. highly skilled (very knowledgeable in php, mysql, security, linux, etc)
> > 2. available regularly (don't have another full-time job)
> > 3. affordable (we're not looking to pay corporate-level pricing.)
> > 4. local (here in the US)
> 
> > We always pay per-project to control our costs.  We don't pay per-hour.
> 
> Jason:
> 
> Perhaps the reason for the difficulty in finding programmers that meet your
> requirements is the current market situation with supply/demand/pricing. I took
> a look at your last project you posted that you wanted done for a firm $2000. I
> did not find it attractive - competitively with other projects available to me,
> the documentation requirements alone sounded like were worth about $2000. Maybe
> I was reading too much into them - if this is the case, this is perhaps
> something to consider - do not make things sound more complex than they ought to be.
> 
> Bidding on the whole project is great for the client, but terrible for the
> programmer. You can easily end up in a big hole. What if you misunderstand the
> requirements when you bid? What if the client starts pushing the limits in the
> interpretation of your agreement? What if you hit some hidden issue that takes
> way too long to deal with? The only time I would ever bid on the whole project
> would be when:
> 
>    * it is small enough to see everything at once and the risks being reduced
> to a zero
>    * to prove myself and get my foot in the door
>    * to be nice for some good cause
> 
> The reality of custom software development is that it is gets exponentially more
> expensive as the size and complexity of the project increases. Good programmers
> know it, and are not likely to bid a reasonable fixed price on something that
> could take forever to finish.
> 
> The solution I believe is to make sure that the client understands how much work
> his money can buy, while the programmer understands the budget limitations of
> the client. They should work together to simpify the requirements so that they
> can create a functional product within some reasonable amount of time.
> 
> --
> Sasha Pachev
> AskSasha Linux Consulting
> http://www.asksasha.com
> 
> .===================================.
> | This has been a P.L.U.G. mailing. |
> |      Don't Fear the Penguin.      |
> |  IRC: #utah at irc.freenode.net   |
> `==================================='
>



More information about the PLUG mailing list