Trade Talk Blog: Algos & Spread Trading

← Back to Trade Talk Blog

UPDATE: If you missed our live broadcast of this ADL Hangout, you can view the recording here.

The next Google Hangout featuring our ADL algorithmic trading tool is set for Wednesday, January 30th, at 3:30p.m. CST. Product Manager John Yoo and Senior Business Analyst Tom Zagara will use the If-Then-Else block to build advanced logic for the exit-side order of the scalper algorithm featured in our previous Hangouts.

To watch our live broadcast, visit TradingTechTV at 3:30 p.m. CST on Wednesday. No registration, login or special software is required.

If you missed the first two live Hangouts, you can watch the recordings below.

Episode 1: Build and launch a basic scalper algo. It joins
and maintains a one-lot bid on a given instrument as long
as the bid quantity is greater than 100. When filled, it places
an exit order at one tick higher than the fill price.

Episode 2: Build the exit-side logic to the
scalper algorithm introduced in the first episode. 
In doing so, we also cover the Value Extractor 
Block and the concept of “virtualization”.

UPDATE: If you missed our live broadcast of the ADL Hangout, you can view the recording here.

Our first Google Hangout (below) featuring TT’s newest algorithmic trading tool, ADL, was so well received that we’re gearing up to produce another live broadcast on Tuesday, December 18th, at 3:30 p.m. CST.

If you missed our first ADL Hangout, click the “play” button above
 to watch the team build and launch an actual trading strategy with ADL

In our second episode, Product Manager John Yoo and Senior Business Analyst Tom Zagara will build the exit-side logic to the scalper algorithm introduced in the first episode. In doing so, they’ll also cover the Value Extractor Block and the concept of “virtualization”.

To watch the live broadcast, come to our YouTube channel, TradingTechTV, at 3:30 p.m. CST on Tuesday. No registration, login or special software is required. If you can’t watch us live, we’ll post the recording to TradingTechTV shortly after the event has concluded.

The elevator panel in my apartment lobby is slightly unusual. It has up and down arrows, as one would expect, but it also has a third button labeled “Dog Run”. This button often makes visitors momentarily hesitate as they reach for the panel.

Dog Run Button:
Keep reading if you don’t know what this button does.

Every day, when I look at this elevator panel, it reminds me that even the most trivial features come with costs. The cost of one additional button may not be readily apparent. But imagine an elevator panel that includes dozens, or perhaps hundreds, of specialized buttons. A panel like this might be completely counter-intuitive and maybe even unusable.

Knowing what I know about the dog run button’s purpose, I’m sure that it’s exactly where it needs to be. However, I often wonder about the thought process that went into its design:

  • What need was this feature designed to address?
  • Was that need worth addressing?
  • If so, is this the optimal implementation?
These are the same questions we ask as we strive to innovate ADL in a way that achieves extraordinary flexibility, yet keeps it slick—both above and below the hood. As the fastest-growing product at TT, ADL has garnered more than 100 enhancement ideas from its users; the innovation that surrounds ADL is truly remarkable.

Below, I’ll shed some light on how we analyze enhancement requests, especially in the context of the three questions mentioned above. My reason for doing this is simple: I want to reassure users that their suggestions don’t disappear into a void. I also want to encourage users to continue to participate in the brainstorm and help us keep the pace of innovation on fire.

The Root Issue

When we visit a doctor, we don’t typically start by handing him or her a list of the prescription drugs we need; the doctor usually makes a diagnosis first.

In the same manner, when a product enhancement is suggested, we don’t usually jump to implementation. Instead, we examine the root issue first.

We typically find that each enhancement request is actually a request for a solution to an issue encountered by the user. An examination often reveals the root issue to be one of the following:

  • A defect that needs to be fixed
  • A need that the user doesn’t know the product already addresses
  • A need that the product doesn’t address

Here’s a real example. During the beta phase of ADL, a user suggested that we introduce the ability to automatically launch an algorithm when the market opens. Upon further interview, we discovered that the user had previously attempted to launch his algo during the pre-open, only to have it pause immediately. As a result, he resorted to manually launching his algo right at the open to gain place-in-queue, and he was looking to automate this manual action.

The root issue here was that all algos were designed to pause during untradable market states (e.g. closed, closing auction, expired, post trading, freeze etc.). What the trader really needed was a way to operate an algo outside of tradable market states. To satisfy this need, we ended up introducing the “Ignore Market State” functionality and the Market State Block.

This was a case where we decided to address the trader’s need. However, that is not always the case – every identified need begs the question: “Is the need worth addressing?”

Scope of the Product

When it comes to determining whether an identified need should fall within the scope of the product, I believe in the “less is more” philosophy. I strive to keep ADL focused on and proficient at its core competencies: market-depth-based analysis and execution.

Some users may conclude that their business needs lie outside of ADL’s scope. I recognize and respect this decision. In fact, I believe focused scope benefits the prospective user; the more focused the product, the easier it is for a user to determine whether or not a product meets his/her needs.

When ADL fits a user’s needs, its focused scope translates into a superior user experience with a product that is highly performant, intuitive and effective.

As ADL matures, we plan to gradually expand the scope to accommodate the usage of technical indicators and fundamental data. However, proficiency will always be prioritized before expansion.

Implementation: Tools, Not Options

Once we determine that a need falls within the scope of the product, we look for a solution.

The core “less is more” principle behind ADL’s implementation is self-evident in the product itself: ADL is a streamlined toolbox of blocks, not a giant collection of checkboxes and drop-down menus.

Look at the image below. I call this the “learning curve vs. flexibility” spectrum. Generally speaking, hard-coded options, such as drop-down menus and checkboxes, lie on the left; they are probably the easiest to use, but also limited in flexibility. APIs are placed on the right; they probably have steep learning curves, but are also very flexible.

Learning Curve vs. Flexibility
ADL’s implementation is deftly balanced about halfway between. It does not require the user to write code, but it does grant sufficient flexibility to excel at its core competencies.

When this principle is applied, the final implementation may end up looking nothing like the original enhancement request, even if it fully addresses the user’s need.

Back to Dog Run…

To come back to where I started, let me tell you what the dog run button does: it calls elevator car #1, which stops at the second floor, where there is an indoor area for walking dogs. Other cars don’t stop at the second floor.

Applying the principles mentioned above, it seems that this button was a downstream effect of an architectural limitation (apparently only one elevator can stop at the second floor) combined with the residents’ need to use the elevator to reach the second floor (apparently residents can’t or won’t use the stairs). Going further upstream, the root cause seems to be the residents’ need to walk their dogs indoors. I don’t own any pets, but it is my humble opinion that owners should walk their dogs outside in the first place…yes, even during Chicago winters. With that said, the indoor area seems like a superfluous feature that can be removed along with the “Dog Run” button.

While I hope I entertained you with my analysis of the dog run button, I hope even more that you gained an understanding of how your ideas and feedback fuel the processes that drive ADL’s evolution. If you’re an ADL user, I hope I’ve inspired you to contribute (or continue contributing) to the innovation of ADL.

UPDATE: If you missed our live broadcast of the ADL Hangout, you can view the recording on our YouTube channel, TradingTechTV.

We recently started moving our corporate IT infrastructure to Google’s enterprise solution. It’s a big change, but I’m really excited about this from a marketing perspective because Google offers some pretty amazing collaboration tools. One of these is Google Hangouts on Air.

This Thursday, November 8th, at 3:30 p.m. CT, we will stream our first Hangout. Our broadcast won’t be formal or scripted, with fancy graphics or an elaborate set. In fact, it won’t even be tied to TT’s official corporate YouTube channel, which will launch soon. But we see incredible potential for Hangouts as a way to talk about our products and engage our users, so we’re going to dive in and experiment.
Our debut broadcast will feature Product Manager John Yoo and Senior Business Analyst Tom Zagara. They will present TT’s newest algorithmic trading tool, ADL. While you watch, they will also build and launch an actual trading strategy—live—using ADL.

To access our Hangout, just come to John’s YouTube channel at 3:30 p.m. CT on Thursday. Our broadcast will automatically play. No registration, login or special software is required. Note Chrome and Internet Explorer are supported, but Firefox may not be compatible. If you can’t make it for the live broadcast, you’ll be able to access a recording on John’s YouTube channel after the event concludes.

Hope you can “hangout” with us.

Back in 2010, Wired columnist Clive Thompson argued that it’s time for all of us—not just software engineers—to learn how to program software1. It’s been nearly two years since that article was written, but I believe it’s still as relevant today as it was then.

As the product manager responsible for TT’s ADL™ visual programming platform, people often ask me if I think traders can learn to code. I tell them, not only can any trader learn to code, but most traders are already engaged in the mental process of writing a program, whether they know it or not.

As an example, consider a successful point-and-click trader who has a rock-star track record. This trader must know his strategy inside-out and execute it with precision. To be specific, he must have the “pathways” of his strategy mapped out, and, if needed, he should be able to articulate them in an organized and systematic manner.

What makes this trader exceptional, however, is not only the fact that his strategy map depicts the main pathways of logic, but that it also covers the inconspicuous “alleys” or contingencies that can arise in the market. The most successful traders consider the “what ifs” and are prepared with maneuvers to deal with such contingencies.

Continue Reading →