Contractors who suck

Discussion in 'Automated Trading' started by lolatency, Jun 19, 2009.

  1. I'm just ranting, but our firm basically bought an off-the-shelf implementation for exchange connectivity. I took a script to run through the entire market activity, find our trades, do some analysis, etc.

    I go looking through the logs calculating latencies, and I end up finding negative latencies because the logs generated by the third party software have the tick timestamps happening -after- when the logs say there are are calls into its execution engine in response. i.e., Tick 12 happens to be the trigger, function is called in response to tick 12, but timestamp associated with function call is before the actual time associated with tick 12.

    F'ing unreal, esp consider how much these bozos got paid. Wasn't my decision, but I'm just writing about it. This would be funny, except that it has implications for me -- namely, that the financier believes his technology choices make my life easier, when in fact they make my life worse. He acts as if I am a quant with all the resources just there and that I can just make stuff because all the hard stuff has been done for me when it really hasn't.

    ... And I think how some of you guys out there want some programmer just to automate your strategy that uses like RSI and moving averages and such, let alone spread-extraction or stat arb. Hiring a programmer is far more difficult than hiring a mechanic or a plumber.

    This generally has implications for the market. The biggest issue I see is that there is all this money being poured into high-frequency trading, but my belief is that the guys who are the investors don't actually understand that when you run and finance this HF stuff, you aren't running a run-of-the-mill finance operation; rather, you are financing a tech company. The other issue I see is that the business guys don't actually trust their tech guys, so they continue to piss away their money and then wonder why they aren't getting any results.
     
  2. ime, that's actually a pretty common occurrence in the industry. i work with multiple executing brokers, those who i delegate as backups have those exact type of problems. from what i see however, is that it's not a trust issue from management to tech, but a complete lack of understanding. i suppose you don't trust though what you don't understand.

    you have guys who think they can just hire a couple programmers and a couple IT guys and it will all come together. when problems arise however, management has no idea how to handle or even identify the issues, while the undirected tech side has to take the reigns. as a result you get inferior product and things never going according to plan. i've never seen an industry, at the low end, where there are more underpaid and overworked guys doing way more than their job description.

    those firms who don't realize they need a highly experienced and highly compensated CTO, are never going to get very far... and if they do, it'll be solely on the backs of their IT guys who will always be 'saving the day'. just not sustainable though, imo.
     
  3. rosy2

    rosy2

    it really is all tech. aside from providing the capital and setting up accounts the non-tech people i have worked in HF dont do anything ... like a trader who just watches an automated strategy run or a quant handicapped due to lack of programming ability.

    there are a few firms that get it like atd several years ago.
     
  4. Agreeing.

    Luckily, some of us can handle both the business and technical side.

    :D :D :D
     
  5. The problem with the vast majority of programmers is they can't see the big picture.

    The ones that can see the big picture do great work and move on to other things.

    Can't see the Forrest for the trees.
     
  6. Eight

    Eight

    I've known programmers, watched them work, served as a listener for their problems, complaints and triumphs.. I would hire a Phd that had a lot of experience coding and some coders. The Phd would coach and write code too... those guys are amazing, the typical coder is not too...

    I hired a guy to code up some test scripts for some project I can't recall, what I do remember was that in four hours he learned a new machine language and had a hundred lines of code up and running... that was one guy with a clear goal and all the information on the processor and language to do the entire job... they typical coder produces 8 lines of code a day after everything is said and done on a large, documented project!! I could not bear to watch a project that went at 8 lines of code per programmer per day... the best business model for efficiency and design is one guy with 25 or less people doing what he says... with more than one guy in charge it gets way worse, for more than 25 people it gets way worse... I worked in consulting companies. Our bread and butter was designing electronics hardware. We could do with a half dozen workers and one tough minded leader what corporations could not do, and we did it regularly and we were paid incredibly well because the corporations came to us after they realized that they were never going to get leading edge work done internally in any short time frame.. we did leading edge products, always an order of magnitude ahead of the last generation, typically in nine months with no stress at all... there was no reason for stress, we had clear direction and we worked reasonably hard..
     
  7. I just lack the patience for dealing with non-tech people in trading. They only slow me down. If, say, the head trader comes over to me and says, "Hey, design this strategy to exploit this relationship", ... he should just leave me alone and let me accomplish the task. My gripe is when people who don't know what they are doing offer their input, demand things be done their way, and then wonder why the project is taking longer. This goes for both quant work and software development. But it also goes for making technology decisions. The business guys should simply not be making tech decisions.

    For example, I recently fielded a request to look at some seasonal component in a given time series. Sure, simple enough, right? Start with the basics: Take the series, look at the correlogram, look at some see if there's room for a basic SARIMA model or something else appropriate, get the stylized results. Go through the usual model selection process. But the guy didn't know what SARIMA was, no idea what a correlogram is, has no idea how to really look at seasonal components.

    So what happens to my time? I have to dumb down the math and spend 4-5x as much time using some idiotic methodology the guy who gave me the request dreamed up. But it also makes no sense, politically, to tell him to get a clue until the guy sees his own meddling as counterproductive.

    We have a "head quant" who doesn't understand what stationarity is in time-series analysis. If we try to correct his incorrect work, he says "that school stuff doesn't work here."

    The patience required for this is tremendous.

    I maintain that only tech people can run tech companies. Paul Ottelini of Intel is maybe the only exception. Carly Fiorina was a disaster at HP. If the CEO has an undergraduate degree in engineering, it's a good sign.
     
  8. Lolatency - I agree thats frustrating but at the same time, you pretty much figured out a way to distinguish yourself from the other developers/quants/programmers whatever.

    The top guys arent't going to want to deal with the 'programmer speak' of the guy that explains things in an obscure way or in C# or whatever. I previously had a developer that was handed to me that more or less spoke in SQL all the time.

    All of the successful IT guys I know can do the technical aspect of the work and explain it in terms the non-technical person can explain.

    Its unfortunate, but a lot of times the non-technical people run the show and have to be worked with.

    Eric
     
  9. MGB

    MGB

    This is the same concept as trumpets in a orchestra. I remember reading somewhere that the optimal number of trumpets in an orchestra was 9. Any less than 9, and the strength of the trumpets goes down. Any more than 9, then the extra trumpets was wasted.

    So, I agree with you. There's an "optimal" size for a development team. Any less than 25, you get bottlenecks in the process. Any greater than 25, you get waste and inefficiency.
     
  10. Without a doubt Lola. I have been dealing with a situation like this that is truly maddening.

    I hired a programmer to code a fairly basic strategy. Turns out the guy is an unbelievable programmer AND a quant genius. He helped take my basic strategy and turn it into a full-blown program. BUT....

    when I offered him a chance to partner up, he scoffed at me. I had some guys lined up that were willing to back me and these strategies with capital. So he delivers the program.... writes a boatload of code in a very short amount of time-- and then disappears!

    So I'm going through the programs and am able to pick out 4 major bugs-- but everything else appears to be working perfectly. So in my mind, its just an few easy fixes and then voila.

    Short story long, the guy turns up 2 months later. In the meantime, I wasn't able to find another programmer who I could trust or who knew anything about what the programs do, and my potential backers walk.

    Now I'm in contact with the original programmer, but he's so backed up on missed work that I am so far down the totem pole I don't know if this will ever be finished. I've already paid him for like 3/4 of the project but the programs are useless to me unless they are working properly.

    Any recommendations on what should i do at this point?
     
    #10     Jun 20, 2009