5 ms·

The accidental HFT firm

132 points by profquail 9y ago

vxxzy 9y ago
From the article: “Reification just becomes legacy without a sufficient lack of architecture.”. This is so eloquently put. Technical Debt is a mess in of itself. But there still exists the chasm Of meeting business needs immediately (time to market) and avoiding technical debt. The sign of a good developer is attempting to look ahead and wonder how else will data need to be presented and manipulated - building the system open-ended enough to allow for the evolution of business needs.
- lmm 9y ago
  > The sign of a good developer is attempting to look ahead and wonder how else will data need to be presented and manipulated - building the system open-ended enough to allow for the evolution of business needs. I've gradually become convinced of just the opposite: a good developer doesn't think ahead at all. The best way to prepare for the evolution of business needs isn't to add extension hooks in the middle of your code, it's to keep the code as simple as possible so that you can change it in a very direct way as and when you need to.
  - hderms 9y ago
    I agree in the sense that your system will be the most flexible provided you use composeable and easy to understand code as much as possible. Overengineering is overengineering because it trades complexity for "flexibility" but the real goal is to keep complexity down as much as possible.
  - arethuza 9y ago
    I've convinced that 95% if the "extension points" I've seen built into code over the years never get used to create extensions - usually because they have significant assumptions about what extensions would be required that turn out to be very wrong.
    - hinkley 9y ago
      There are subtle ways to add extension points that most people won’t even notice. For instance, putting related code into a data structure allows you to add more to it later without replumbing the whole system (as opposed to functions with five arguments). With enough experience with refactoring, just choosing a structure that’s easy to refactor can serve as an extension point. (I have even tricked people into implementing a feature the way I had it in my head by writing the intermediate version in such a way to suggest a simple change for part 2.)
    - mickronome 9y ago
      Never add any extension points you don't already need, but design as if you could suddenly be tasked with adding all kinds of weird ones, but mostly without spending any significant time. Try to make sure that reasonable extensions are cheap to add, and that even some of the more unreasonable ones are at least possible without complete system redesign. This should not significantly impact either implementation time, or design time. But it will almost certainly make you avoid some really bad design choices that make quite plausible changes extremely expensive. Good design is more about avoiding obvious traps than finding a path to nirvana.
  - kbenson 9y ago
    It's not always about a hook, sometimes it's about where yo break into subsystems and subfunctions. Breaking it up at the right point allows for easy extension through writing new components later, while requiring the least amount of modifications to the production code (and thus hopefully less bugs introduced into working code-paths). Additionally, how you represent your data may allow for easier extension of the data type or additional, related data type processing later. I do a lot of data mining, and the first step is always securing the data source and archiving it. There have been times where I wasn't able to revisit the project and finish the actual parser of the data for 5-6 months, at which point I can run through the old data. Other times, I'll write the parser but we'll only be parsing a subset of the data we acqiured. The additional unparsed portionisn't necessarily without merit, it's just not something we are dealing with yet (either because it's still of an unknown quality, or requires more effort than we want to spend at that moment). Knowing it's there and that it may need to be parsed in the future can subtly affect your design such that you leave yourself the openings you'll later need to easily parse this additional data. Sometimes that's as simple as just avoiding situations that would make it extremely cumbersome later, and not necessarily actively making it easier. I'm not sure ignoring something as obvious as this makes one a good developer, but what's "obvious" and what isn't is actually quite different at different software engineering experience levels.
  - mickronome 9y ago
    Depends on which meaure of good in use obviously, but I have never seen anyone capable of being efficient over significant time spans without in some way having design and architecture be guided by principles that balance cost of change, cost of implementation, and difficulty of understanding. Ignoring cost of change can be absolutely devastating in the long run, but believing you can somehow scry the future for all possible extension points necessary is equally so. Designing for (anticipated) change in my mind is not at all about adding hooks, API's, or any code at all for that matter. I think of it more like making sure your system respect analogues to gravity and the other natural laws as best translated into the more abstract relations relevant for the particular kind of system you are building. One could call it programmer and refactoring friendly design and not miss the target by much.
- kbenson 9y ago
  I don't know if it's because it's early and my coffee isn't done yet, or that's too dense of a phrase, it's just me, or some combination thereof, but it took two reads of that phrase, a complete and thoughtful read of your comment, and then two additional reads of that phrase before I was able to unpack it enough to makes sense of it and how your comment tied into it. I'm leaning towards the coffee explanation, but multiple negative (or negative connotating) words probably didn't help...
  - mhurd 9y ago
    Yeah, it's a bit dense. Sorry about that.
    - kbenson 9y ago
      No need to apologize, I agree with the assessment. In the clear light of day, that comment was just me vomiting words onto the forum in the vain attempt to justify the effort I put into grokking that comment. :/
      - mhurd 9y ago
        "The best architecture is no architecture" ... became a popular catchphrase for me in the early nineties. I built a streaming kind of trading system back then that integrated data flow and functional views, as some problems were easier to grok in one and harder in the other. Just thinking about things as simple functions: a = f(b) and code as a way of organising like with like worked for me. Sometimes the object approach gets a bit silly. Organisation by the first parameter being special doesn't always work too well. For example, GAMS is a better classification for math than simply putting all vector or matrix code in the one classification. Curation is hard at the end of the day.
        mslate 9y ago
        How much automated/acceptance/regression testing did you guys have? Would "releases" cause major brick-shitting (like the instance where Mr. L deployed a problematic release)?
rburhum 9y ago
Thank you, thank you, thank you for this. Such an interesting look into the world of HFT. I particularly like the parte of tapping into the cable directly, looking at the first bytes of the packet, and sending the order before the entire packet arrived. Awesome stuff!
twic 9y ago
I was reading through this, seeing some similarities to my work. Then i got a real shock at the end: > Previously published under the pseudonym Thomas Anderson. Er, that's me!
- deleted 9y ago
  [deleted]
- erpellan 9y ago
  I think it's a matrix reference. "Tell me Mr Anderson, how will you make a phone call... if you're unable to speak?"
  - mhurd 9y ago
    That's correct. Automated Trader requested it to be published under a pseudonym when it when out in 2016. I didn't object and chose the Matrix reference.
tacon 9y ago
>Things got even better for us in Korea. Now that I had the bits streaming off one by one, or at least byte by byte, you could see that the packets took a long time on the wire. Milliseconds. A common technique in network monitoring is slicing, where you just take the first part of the packet. I did this with the HDLC bypass code and we were now a long way ahead of the game as the bid and ask fields were at the front of the quote packets. Save 100 bytes at 128 kbps and you’re 6.1 milliseconds ahead. As specifications changed and KRX feeds sped up, our advantage reduced but life remained good. Now we were sending out orders before the data packet arrived. I love it when HFT seems to violate causality.
ISL 9y ago
Best post I've seen on HN in a month or two -- thanks for posting.
walshemj 9y ago
x.25 there is a blast from the past
polskibus 9y ago
This is great, I wonder what is such a talented developer doing these years? Has tech moved so much that there are less and less HFT jobs? Or is it the opposite? On a side note - can anyone recommend a book with similar stories? Ie. from the trenches of development, finance + software?
- lingua_franca 9y ago
  Yes HFT is dying, just check out how many HFT firms either closed down or sold themselves in recent year. You might want to read book "Flash Boys" by Michael Lewis.
  - polskibus 9y ago
    Why is that? Did someone won and took it all ? What happened?
  - mhurd 9y ago
    I think it has become more polarised as jitter (as a consequence of latency) has come down. Also more democratised and many vendors provide good solutions. Still, quite good profits in the system. See: https://meanderful.blogspot.com.au/2018/01/australian-popular-hft-tax-assessment.html https://meanderful.blogspot.com.au/2018/01/australian-popula...
    - polskibus 9y ago
      Could you explain the information edge that asset managers have? I always thought the big guys were the easiest targets. What kind of algos (you mention that in the article) can they employ to defend or just perform better? I'd love to read more about it, it's very interesting - can you point me towards some resources ? I'm not in finance but this "war" has always fascinated me.
      - mhurd 9y ago
        The primary information edge an asset manager has is that they have large enough order that it is not immediately consumable. This will have a price impact. So, if they take the HFT price on offer at a market, the HFT will lose money as the price will go against them. Most of the algos I'm thinking about there are designed to minimise market impact. They do this by spreading the order over time and/or space (venues) as well as by balancing passivity and aggressiveness. There is not a terrible lot that is written that is unbiased as most have a particular POV. Market microstructure textbooks are perhaps the healthiest place to start ;-)

132 points by profquail 9y ago

From the article: “Reification just becomes legacy without a sufficient lack of architecture.”. This is so eloquently put. Technical Debt is a mess in of itself. But there still exists the chasm Of meeting business needs immediately (time to market) and avoiding technical debt. The sign of a good developer is attempting to look ahead and wonder how else will data need to be presented and manipulated - building the system open-ended enough to allow for the evolution of business needs.

lmm 9y ago
> The sign of a good developer is attempting to look ahead and wonder how else will data need to be presented and manipulated - building the system open-ended enough to allow for the evolution of business needs. I've gradually become convinced of just the opposite: a good developer doesn't think ahead at all. The best way to prepare for the evolution of business needs isn't to add extension hooks in the middle of your code, it's to keep the code as simple as possible so that you can change it in a very direct way as and when you need to.
- hderms 9y ago
  I agree in the sense that your system will be the most flexible provided you use composeable and easy to understand code as much as possible. Overengineering is overengineering because it trades complexity for "flexibility" but the real goal is to keep complexity down as much as possible.
- arethuza 9y ago
  I've convinced that 95% if the "extension points" I've seen built into code over the years never get used to create extensions - usually because they have significant assumptions about what extensions would be required that turn out to be very wrong.
  - hinkley 9y ago
    There are subtle ways to add extension points that most people won’t even notice. For instance, putting related code into a data structure allows you to add more to it later without replumbing the whole system (as opposed to functions with five arguments). With enough experience with refactoring, just choosing a structure that’s easy to refactor can serve as an extension point. (I have even tricked people into implementing a feature the way I had it in my head by writing the intermediate version in such a way to suggest a simple change for part 2.)
  - mickronome 9y ago
    Never add any extension points you don't already need, but design as if you could suddenly be tasked with adding all kinds of weird ones, but mostly without spending any significant time. Try to make sure that reasonable extensions are cheap to add, and that even some of the more unreasonable ones are at least possible without complete system redesign. This should not significantly impact either implementation time, or design time. But it will almost certainly make you avoid some really bad design choices that make quite plausible changes extremely expensive. Good design is more about avoiding obvious traps than finding a path to nirvana.
- kbenson 9y ago
  It's not always about a hook, sometimes it's about where yo break into subsystems and subfunctions. Breaking it up at the right point allows for easy extension through writing new components later, while requiring the least amount of modifications to the production code (and thus hopefully less bugs introduced into working code-paths). Additionally, how you represent your data may allow for easier extension of the data type or additional, related data type processing later. I do a lot of data mining, and the first step is always securing the data source and archiving it. There have been times where I wasn't able to revisit the project and finish the actual parser of the data for 5-6 months, at which point I can run through the old data. Other times, I'll write the parser but we'll only be parsing a subset of the data we acqiured. The additional unparsed portionisn't necessarily without merit, it's just not something we are dealing with yet (either because it's still of an unknown quality, or requires more effort than we want to spend at that moment). Knowing it's there and that it may need to be parsed in the future can subtly affect your design such that you leave yourself the openings you'll later need to easily parse this additional data. Sometimes that's as simple as just avoiding situations that would make it extremely cumbersome later, and not necessarily actively making it easier. I'm not sure ignoring something as obvious as this makes one a good developer, but what's "obvious" and what isn't is actually quite different at different software engineering experience levels.
- mickronome 9y ago
  Depends on which meaure of good in use obviously, but I have never seen anyone capable of being efficient over significant time spans without in some way having design and architecture be guided by principles that balance cost of change, cost of implementation, and difficulty of understanding. Ignoring cost of change can be absolutely devastating in the long run, but believing you can somehow scry the future for all possible extension points necessary is equally so. Designing for (anticipated) change in my mind is not at all about adding hooks, API's, or any code at all for that matter. I think of it more like making sure your system respect analogues to gravity and the other natural laws as best translated into the more abstract relations relevant for the particular kind of system you are building. One could call it programmer and refactoring friendly design and not miss the target by much.
kbenson 9y ago
I don't know if it's because it's early and my coffee isn't done yet, or that's too dense of a phrase, it's just me, or some combination thereof, but it took two reads of that phrase, a complete and thoughtful read of your comment, and then two additional reads of that phrase before I was able to unpack it enough to makes sense of it and how your comment tied into it. I'm leaning towards the coffee explanation, but multiple negative (or negative connotating) words probably didn't help...
- mhurd 9y ago
  Yeah, it's a bit dense. Sorry about that.
  - kbenson 9y ago
    No need to apologize, I agree with the assessment. In the clear light of day, that comment was just me vomiting words onto the forum in the vain attempt to justify the effort I put into grokking that comment. :/
    - mhurd 9y ago
      "The best architecture is no architecture" ... became a popular catchphrase for me in the early nineties. I built a streaming kind of trading system back then that integrated data flow and functional views, as some problems were easier to grok in one and harder in the other. Just thinking about things as simple functions: a = f(b) and code as a way of organising like with like worked for me. Sometimes the object approach gets a bit silly. Organisation by the first parameter being special doesn't always work too well. For example, GAMS is a better classification for math than simply putting all vector or matrix code in the one classification. Curation is hard at the end of the day.
      - mslate 9y ago
        How much automated/acceptance/regression testing did you guys have? Would "releases" cause major brick-shitting (like the instance where Mr. L deployed a problematic release)?

rburhum 9y ago

Thank you, thank you, thank you for this. Such an interesting look into the world of HFT. I particularly like the parte of tapping into the cable directly, looking at the first bytes of the packet, and sending the order before the entire packet arrived. Awesome stuff!

twic 9y ago

I was reading through this, seeing some similarities to my work. Then i got a real shock at the end: > Previously published under the pseudonym Thomas Anderson. Er, that's me!

deleted 9y ago
[deleted]
erpellan 9y ago
I think it's a matrix reference. "Tell me Mr Anderson, how will you make a phone call... if you're unable to speak?"
- mhurd 9y ago
  That's correct. Automated Trader requested it to be published under a pseudonym when it when out in 2016. I didn't object and chose the Matrix reference.

tacon 9y ago

>Things got even better for us in Korea. Now that I had the bits streaming off one by one, or at least byte by byte, you could see that the packets took a long time on the wire. Milliseconds. A common technique in network monitoring is slicing, where you just take the first part of the packet. I did this with the HDLC bypass code and we were now a long way ahead of the game as the bid and ask fields were at the front of the quote packets. Save 100 bytes at 128 kbps and you’re 6.1 milliseconds ahead. As specifications changed and KRX feeds sped up, our advantage reduced but life remained good. Now we were sending out orders before the data packet arrived. I love it when HFT seems to violate causality.

ISL 9y ago

Best post I've seen on HN in a month or two -- thanks for posting.

walshemj 9y ago

x.25 there is a blast from the past

polskibus 9y ago

This is great, I wonder what is such a talented developer doing these years? Has tech moved so much that there are less and less HFT jobs? Or is it the opposite? On a side note - can anyone recommend a book with similar stories? Ie. from the trenches of development, finance + software?

lingua_franca 9y ago
Yes HFT is dying, just check out how many HFT firms either closed down or sold themselves in recent year. You might want to read book "Flash Boys" by Michael Lewis.
- polskibus 9y ago
  Why is that? Did someone won and took it all ? What happened?
- mhurd 9y ago
  I think it has become more polarised as jitter (as a consequence of latency) has come down. Also more democratised and many vendors provide good solutions. Still, quite good profits in the system. See: https://meanderful.blogspot.com.au/2018/01/australian-popular-hft-tax-assessment.html https://meanderful.blogspot.com.au/2018/01/australian-popula...
  - polskibus 9y ago
    Could you explain the information edge that asset managers have? I always thought the big guys were the easiest targets. What kind of algos (you mention that in the article) can they employ to defend or just perform better? I'd love to read more about it, it's very interesting - can you point me towards some resources ? I'm not in finance but this "war" has always fascinated me.
    - mhurd 9y ago
      The primary information edge an asset manager has is that they have large enough order that it is not immediately consumable. This will have a price impact. So, if they take the HFT price on offer at a market, the HFT will lose money as the price will go against them. Most of the algos I'm thinking about there are designed to minimise market impact. They do this by spreading the order over time and/or space (venues) as well as by balancing passivity and aggressiveness. There is not a terrible lot that is written that is unbiased as most have a particular POV. Market microstructure textbooks are perhaps the healthiest place to start ;-)