5 ms·

Some unit tests would be nice. Maybe even a special folder full of tests that know when laws have been broken.

azinman2 11y ago
Probably exists now, and not before. Writing this software would be very scary for me -- I'm confident in my work for the most part but I'm only human. To then let a "for-loop" go wild making thousands of trades per second on the entire market with real money against other high frequency traders no less.. man... you gotta be really really really really sure of your code!
- mathgenius 11y ago
  Yeah, well, fkups happen, you just gotta make sure you are making more money than you lose in those incidents.
  - smoothgrammer 11y ago
    Or you just write a test that checks to make sure you don't screw up.
    - mathgenius 11y ago
      If you're designing a new airliner then yeah, you can't screw up, and you end up taking years to deploy. In the HFT world, you may have only days, or sometimes hours, to deploy. Yes you still write tests, and a bazillion safety checks when you deploy, but if you manage your risk down to zero then this is definitely not the most profitable way to go.
- smoothgrammer 11y ago
  It is not about confidence. It is about ownership and being a good engineer. A good engineer would have cared about the code base and ensured that a test would fail, a use case would be linked to that failure, and someone would see that they have now violated a regulation. Then if the regulation changed, someone would grep through the use cases, and see what behavior is occuring/ how to modify the code base to cope with the change in regulations (this occurs a lot). Of course most finance firms don't do this and actually violate regulations all the time. There is literally a gold mine for the SEC/FINRA to go after, but the government is fairly incompetent at mining through the data and holding companies accountable. The reason being that they don't pay enough to hire the talent that would uncover the violations.
  - vitalyd 11y ago
    I'd be surprised if they didn't make postmortem changes to prevent such incidents in the future. Your posts in this thread imply that no mistake should ever happen, but let's be real - mistakes will always happen, the key is to do proper postmortem analysis and learn from them (and obviously prevent recurrences).
    - smoothgrammer 11y ago
      Some mistakes, yes. But this was a case of such a basic and clear cut use case that should have been tested. My understanding is that companies such as this rely purely on manual testing. Thus it is easy for things to slip through the cracks. Usually they never get hit by penalties or get caught so the pressure to do better is not there.
  - tbrownaw 11y ago
    Real engineers are like true Scotsmen, because you can never have enough process. In this case, of course tests really do prove the absence of bugs rather than just (not) proving their presence. I really don't like the whole "unit tests lets you not worry about breaking things" view. That's not confidence, it's overconfidence. And it doesn't even mostly work for things where "correct" is more fuzzy than "eventually produces this exact output".
    - smoothgrammer 11y ago
      It is confidence. It is the right tool for the job. What would you propose as an alternative?
x0054 11y ago
Or how about at least some code documentation. In this case the programer deleted the code because he didn't understand why it was there. Well a simple "# Needed to Comply with regulation X" would probably have prevented this problem.
- osi 11y ago
  There's a specific incantation required to send the routed ISO orders via BATS as mentioned in the article. I can see how a refactoring might accidentally change that. With that said, libraries that send orders to exchanges are required by the exchanges to be certified against their expected behaviors. If you want to send routed ISO orders, you have to test that with them. When making changes to said libraries, it can often be good to re-certify to ensure things are still working as expected.

Probably exists now, and not before. Writing this software would be very scary for me -- I'm confident in my work for the most part but I'm only human. To then let a "for-loop" go wild making thousands of trades per second on the entire market with real money against other high frequency traders no less.. man... you gotta be really really really really sure of your code!

mathgenius 11y ago
Yeah, well, fkups happen, you just gotta make sure you are making more money than you lose in those incidents.
- smoothgrammer 11y ago
  Or you just write a test that checks to make sure you don't screw up.
  - mathgenius 11y ago
    If you're designing a new airliner then yeah, you can't screw up, and you end up taking years to deploy. In the HFT world, you may have only days, or sometimes hours, to deploy. Yes you still write tests, and a bazillion safety checks when you deploy, but if you manage your risk down to zero then this is definitely not the most profitable way to go.
smoothgrammer 11y ago
It is not about confidence. It is about ownership and being a good engineer. A good engineer would have cared about the code base and ensured that a test would fail, a use case would be linked to that failure, and someone would see that they have now violated a regulation. Then if the regulation changed, someone would grep through the use cases, and see what behavior is occuring/ how to modify the code base to cope with the change in regulations (this occurs a lot). Of course most finance firms don't do this and actually violate regulations all the time. There is literally a gold mine for the SEC/FINRA to go after, but the government is fairly incompetent at mining through the data and holding companies accountable. The reason being that they don't pay enough to hire the talent that would uncover the violations.
- vitalyd 11y ago
  I'd be surprised if they didn't make postmortem changes to prevent such incidents in the future. Your posts in this thread imply that no mistake should ever happen, but let's be real - mistakes will always happen, the key is to do proper postmortem analysis and learn from them (and obviously prevent recurrences).
  - smoothgrammer 11y ago
    Some mistakes, yes. But this was a case of such a basic and clear cut use case that should have been tested. My understanding is that companies such as this rely purely on manual testing. Thus it is easy for things to slip through the cracks. Usually they never get hit by penalties or get caught so the pressure to do better is not there.
- tbrownaw 11y ago
  Real engineers are like true Scotsmen, because you can never have enough process. In this case, of course tests really do prove the absence of bugs rather than just (not) proving their presence. I really don't like the whole "unit tests lets you not worry about breaking things" view. That's not confidence, it's overconfidence. And it doesn't even mostly work for things where "correct" is more fuzzy than "eventually produces this exact output".
  - smoothgrammer 11y ago
    It is confidence. It is the right tool for the job. What would you propose as an alternative?

x0054 11y ago

Or how about at least some code documentation. In this case the programer deleted the code because he didn't understand why it was there. Well a simple "# Needed to Comply with regulation X" would probably have prevented this problem.

osi 11y ago
There's a specific incantation required to send the routed ISO orders via BATS as mentioned in the article. I can see how a refactoring might accidentally change that. With that said, libraries that send orders to exchanges are required by the exchanges to be certified against their expected behaviors. If you want to send routed ISO orders, you have to test that with them. When making changes to said libraries, it can often be good to re-certify to ensure things are still working as expected.