Use vWorker.net, the payment is held in escrow until the work is complete and if he doesn't do the correct job according to your text-written specifications then the arbitration panel will not pay him or ask that he completes it. It's a very good/fair/well done system.
Programmers think they are like 007
- Thread starter virtualmoney
- Start date
use one of the escrow accounts aforementioned and do things in well defined milestones... payment guaranteed at the milestone, option to continue the work for both sides of the table at each milestone... I'd specify working and documented code...
you can check the work to see if it's up to your standards early on, you CAN tell a coder what you want down to the details like readable and understandable documentation, coded in modules, etc...
I've seen documentation that was comments in the code describing what each line was doing, that was an insult, that was documentation that could have been added in by anybody after the fact. Documentation is a description of what each module does, it's inputs and outputs. I love flowcharts for the bigger picture, most programmers don't seem to like those at all but if you flowchart a process THEN code it, you won't have to debug a lot of stuff...
you can check the work to see if it's up to your standards early on, you CAN tell a coder what you want down to the details like readable and understandable documentation, coded in modules, etc...
I've seen documentation that was comments in the code describing what each line was doing, that was an insult, that was documentation that could have been added in by anybody after the fact. Documentation is a description of what each module does, it's inputs and outputs. I love flowcharts for the bigger picture, most programmers don't seem to like those at all but if you flowchart a process THEN code it, you won't have to debug a lot of stuff...
A related issue is that non-programmer often don't appreciate the level of detail required to fully implement what's being specified.
It's generally not the calculations that are at issue, but all the other things that could affect the validity of the calculations: crossed quotes, low volume, bid/ask spread much wider than normal, slow network (ISP problems maybe), unannounced broker API "upgrades", etc.
The only way for a relationship to be productive is for the trader and developer to "co-develop" the software, and consider it a joint project.
Personally, I've co-developed several systems with others. Often I coded things, but just as often I discovered things that ultimately become part of the final software and were outside the original specification. So unless both parties consider it a joint project I just don't see how it can succeed.
It's generally not the calculations that are at issue, but all the other things that could affect the validity of the calculations: crossed quotes, low volume, bid/ask spread much wider than normal, slow network (ISP problems maybe), unannounced broker API "upgrades", etc.
The only way for a relationship to be productive is for the trader and developer to "co-develop" the software, and consider it a joint project.
Personally, I've co-developed several systems with others. Often I coded things, but just as often I discovered things that ultimately become part of the final software and were outside the original specification. So unless both parties consider it a joint project I just don't see how it can succeed.
Maybe programmers know the FACT that all frequent traders lose, so you'll have no money to pay them after the job is done?Quote from virtualmoney:
"Mr Bond, your reputation precedes you"
----- Original Message -----
because my reputation is good
On Tue, Sep 7, 2010 at 2:38 PM, I wrote:
How do I know you will code the ea completely&correctly after
Payment?
Coder wrote:
sorry, but my policy is that I can start working after full advancepayment
On Tue, Sep 7, 2010 at 6:36 AM, I wrote:
> The price is ok. Please proceed to code the EA and I will
> pay you when I have tested the EA to be working correctly.
Fact or ... Experience? then they should not take up the deal unless they already lost first and need to gather any payment asap to top up their own margin.
Well spoken. Common goal makes sense.
The programmer I use told me a major problem he has is the client is too vague with their description, ie they do not specify in detail exactly what they want. Many clients might say for example "make me a buy and sell signal formula" but haven't go a clue on what parameters the signals should be looking at.
The client wants to be spoon fed and is clueless on how to communicate their thoughts.
So if programmer makes a code which gives a buy and sell signal using for example volatility, the client then may say "No I didn't want it this way"
I'd say that coding for strangers would be a tough game as time is money and dumb clients will cost the programmer money.
The client wants to be spoon fed and is clueless on how to communicate their thoughts.
So if programmer makes a code which gives a buy and sell signal using for example volatility, the client then may say "No I didn't want it this way"
I'd say that coding for strangers would be a tough game as time is money and dumb clients will cost the programmer money.
Turn it around.
How does he know you'll pay?
He's not asking for anything different of you than you're asking of him.
This happens all the time, sometimes from contractor incompetence, more often from clients not understanding that detailed planning is itself a job that needs to be paid for.