-
Notifications
You must be signed in to change notification settings - Fork 23
Logbook 3
A Logbook entry written by @tpierrain
The mob got back to work today (but without Ozgur this time).
As I was out of the office the week before for a business trip (and still a little bit jet-lagged I guess ;-) I tried to resynch myself with the ongoing work. After this brief catch up for me, Mendel took the keyboard and we continued a previous refactoring initiated to make our code more coherent (by replacing every .NET events by callbacks transmitted as argument to methods). Indeed, part of the code was raising .NET events, other part was expecting callbacks. After few refactoring steps, we realized that we were not all completely enthusiastic with this decision to replace .NET events with callbacks (the ones given to the IOrder.Route() method for instance).
Since we didn't have enough pros/cons arguments on that topic, we then decided to postpone this design decision until we have enough information to take it. We also started to instruct this design debate with pros/cons:
# Events vs. callbacks transmitted to methods
## .NET Events pros
+ More visible / prominent part of the domain
+ Appropriated for fan-out notification (one to many)
## Callbacks pros
+ Forces the Registration (not optional like .NET event subscriptions)
+ Per-method-call registration; no need to rely on closure to match callback instance with the proper context
TBC...
One of the pro-callback argument was also to be more aligned with the possible F# implementation of the SOR. But we finally agreed that we rather go full F# or full C# (i.e. leveraging on C# concepts such as events) rather than having a kind of lowest common denominator implementation for the SOR.
As a consequence, we frozen our refactoring efforts, and we temporary stick to the ol' .NET event option by exposing a new Failed event on the InvestorInstruction type.
Because we also chat a while about the semantic of the InvestorInstruction. Should we keep it or replace it with the notion of ExecutionStrategy that traders seem to refer also instead? Proper timing for "BA" Cyrille to join us, and to explain that every-time traders were talking about strategies, they were referencing to algorithms (e.g. WAP, T-WAP, V-WAP).
Concretely speaking, that means that our Investor Instruction is still a valuable name (e.g. as an investor, I intent to cut my position on ...), but that we'll also have to add an execution strategy type as part of the Investor Instruction arguments.
Fortunately for us Mendel had the keyboard (cause he's blazzing fast with it ;-). Unfortunately for him, my default Resharper settings was set to Visual Studio scheme (not the Resharper 2.x/IntelliJ he was used to). I said unfortunately, because even when he changed the keyboard scheme for the session, it seemed that some of the short-cuts were still disabled (probably due to some collision with VS.NET existing short-cuts). Sad Panda...
"We shouldn't need such kind of tools... and NCrunch too BTW"" (smile)
I still don't know whether he's really serious or not with those statements... but that makes us tease ourselves gently and adds some fun to our sessions (from a personal point of view, I really enjoy running gags)
We finished this short session by allowing partial executions to be specified at the investor level so that our ShouldFaileWhenOrderExceedsAllMarketCapacityAndPartialExecutionNotAllowed acceptance test finally passes, using this brand new Failed event.
From a personal point of view, I hope that I'll be more active/efficient next time. That's all folks!
A Logbook entry written by Thomas P
Today's session was mainly between Mendel and I. Cyrille was among us at the beginning, but he quickly left the room to attend another meeting after having contributed to our topic-of-the-day-debate (i.e. what's the next step for us).
And the winner was... to make the SOR able to success -when requested liquidity is available across the markets- despite the fact that one or more limit orders are rejected by a market (remember? we previously implemented a weight average execution strategy - what we called Market sweep).
Mendel and I started then to introduce the concept of ExecutionState. A kind of "fil-rouge" for the state of the InvestorInstruction during its complete life-cycle. After few extract methods and refactoring steps, we were able to keep the execution history of any investor instruction in its corresponding ExecutionState (transmitted to the Solver for instance).
In that new design, the retry attempts are initiated directly from the SmartOrderRoutingEngine registered callback (for the OrderFailed event of the OrderBasket). Now, we ask the Solver for another round to complete total execution if needed.
To prevent from facing infinite loops on limit orders retry (due to rounding issues with the markets weight average strategy, or if it's really impossible to execute all the InvestorInstruction for instance), we introduced 2 things:
- A goodTill option (nullable DateTime) on the investor instruction.
- A mechanism to prevent the SOR from sending limit orders to a Market after it send us 3 order rejections.
In fact, the bell rang while we were trying to green a test demonstrating the second mechanism (i.e.: ShouldStopSendingOrdersToAMarketAfter3Rejects() acceptance test). But Mendel and I have seen few things that we may improve on our code design once we'll make our test green.
TBC...