Programmers think they are like 007

Discussion in 'Chit Chat' started by virtualmoney, Sep 10, 2010.

  1. 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.
     
    #11     Sep 11, 2010
  2. Eight

    Eight

    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...
     
    #12     Sep 11, 2010
  3. bln

    bln

    Break it up in smaller payments, something like milestones and one for final delivery and one after review. Thats a setup that both parties should be able to accept.

    Milestone1 - 10%
    ...
    Milestone5 - 10%
    Final delivery - 25%
    After test and review the remaining 25%
     
    #13     Sep 11, 2010
  4. 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.
     
    #14     Sep 11, 2010
  5. Maybe programmers know the FACT that all frequent traders lose, so you'll have no money to pay them after the job is done?
     
    #15     Sep 11, 2010
  6. 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.:)
     
    #16     Sep 11, 2010
  7. Well spoken. Common goal makes sense.
     
    #17     Sep 11, 2010
  8. themickey

    themickey

    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.
     
    #18     Sep 12, 2010
  9. 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.
     
    #19     Sep 12, 2010
  10. 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.
     
    #20     Sep 12, 2010