3 ms·

There's a lot of ignorance going on in the articles out there. I know nothing of the internals of the project but it was commissioned to replace a system that h

by aidos 16y ago

There's a lot of ignorance going on in the articles out there. I know nothing of the internals of the project but it was commissioned to replace a system that has frequent outages (including a major one last week). Teething issues, while not desirable, are inevitable at such an early stage of the project. It's bound to be an incredibly complicated system. I feel for the devs working on it. Bet they didn't have a fun morning....

bmj 16y ago
Does this same logic apply to, say, a control module in a space craft, or the software behind an MRI machine?
- nialo 16y ago
  Those are orders of magnitude easier to test.
  - CWuestefeld 16y ago
    I'm not sure about that. The testing problems are different, but not harder. An exchange has to deal with massive scale, but isn't hugely complex (relative to a spacecraft, which deals with fault tolerance and integrating many different inputs; or the mathematical complexity of medical imaging). It seems to me that most aspects of scale aren't too difficult to emulate, given sufficient computing resources to generate the load.
- SoftwareMaven 16y ago
  Any time you are dealing with a system with that many users, you are going to introduce a lot of chaos (in its mathematical sense). Chaos is nearly impossible to test for because there are just too many permutations. You are (probably) right that any particular piece of a trading system would be easier to build and test than the examples you gave, but in aggregate, I think it would be much more difficult.
  - spitfire 16y ago
    No it isn't. It's a matter of maturity and mindset. The avionics industry has it - they use Ada and formal methods, most of the rest of the software development world doesn't. and they pay the price. Honestly I questioned the competence of the LSE when they outsourced their development for the first windows based trading system to a consulting shop. Simply put, they outsourced a core, critical part of the UK's financial infrastructure to boobs. However, I do see some hope in haskell and ocaml entering the financial market.

by aidos 16y ago

bmj 16y ago

Does this same logic apply to, say, a control module in a space craft, or the software behind an MRI machine?

nialo 16y ago
Those are orders of magnitude easier to test.
- CWuestefeld 16y ago
  I'm not sure about that. The testing problems are different, but not harder. An exchange has to deal with massive scale, but isn't hugely complex (relative to a spacecraft, which deals with fault tolerance and integrating many different inputs; or the mathematical complexity of medical imaging). It seems to me that most aspects of scale aren't too difficult to emulate, given sufficient computing resources to generate the load.
SoftwareMaven 16y ago
Any time you are dealing with a system with that many users, you are going to introduce a lot of chaos (in its mathematical sense). Chaos is nearly impossible to test for because there are just too many permutations. You are (probably) right that any particular piece of a trading system would be easier to build and test than the examples you gave, but in aggregate, I think it would be much more difficult.
- spitfire 16y ago
  No it isn't. It's a matter of maturity and mindset. The avionics industry has it - they use Ada and formal methods, most of the rest of the software development world doesn't. and they pay the price. Honestly I questioned the competence of the LSE when they outsourced their development for the first windows based trading system to a consulting shop. Simply put, they outsourced a core, critical part of the UK's financial infrastructure to boobs. However, I do see some hope in haskell and ocaml entering the financial market.