Thursday, March 1, 2012

Building a trading strategy

One common aspect typifies almost all of the trading robots that we develop. The finished product does not exactly follow the initial design.

All programming projects proceed in one of two ways. You can either code a task from the peak to the bottom, or you can build from the bottom to the top. The former alternative represents the old way of thinking, especially within higher education. When lecturors assign a project, the conditions never change. The task remains static.

Real life hardly ever occurs like that. Instead, people change their minds. They view the product in progress and arrive at the conclusion that a small adjustment may substantially modify the outcome. The expert advisor programmer is forced to regularly habituate to the changing goal posts.

I always tell clients that they will recondition their minds about several of the rules during the project. Many stand firm that they will not. The customers do, after all, anticipate that the conditions will be correct.

Then, the rules unavoidably recondition for most of the clients. Theory falls apart in practice. The traders uncover the real problems that expert advisors face in the market.

Programmers developed a new method to harmonize with the steadily shifting rules. It's termed agile development. This pickle doesn't only occur with forex traders. It also happens to businesses constructing web sites, database coders saving information, and just about any project that involves human beings. Human beings are prone to changing their minds. It's our nature. Agile development is the programmer's acknowledgement that getting upset at customers for changing their minds is not reasonable.

The agile blueprint segments a project into time periods with an arranged list of goals. The team decides which objectives are most valuable and achievable within the established window. The period starts and everyone rushes to accomplish as much code as possible. Everyone regroups after 2-6 weeks to sort out the progress and to send the updated version to the customer.

Most expert advisor tasks only span a few weeks, so a precise carbon copy of the agile approach would not adapt very well with developing a trading robot. We chuck the strategy development method on its head by allocating graded goals with a cutoff of 1-2 business days. The goal is to aid communication, which is inevitably the most challenging obstacle in this field. We also make the method less rigid to speed things along.

The quick answers lead to a series of yes/no answers. The client either gets excited that it works correctly, or more likely, feels that we did not interpret him accurately. The authentic goal of this strategy is to get the user away from explaining the idea for the 1,000th time in the same, identical way. The last brief did not help the plan move along. Client feedback from functioning software guides the coder into comprehending the thought on his own without making the consumer believe that he's echoing himself.

I like to think of it as the client steering the driver's wheel while the programmer controls the gas pedal. The strategy development process only works when the steering and power move in synch.

Overcoming expert advisor programming challenges




When customers feel like an expert advisor has not made the desired progress, the first step is to assign goals one at a time. Too often, we receive reports with 20 different bugs. The emphasis on priority falls away as the desire to "fix everything and fix it now" drowns out the details of each request. I always like to take a step back and reaffirm our commitment to developing the strategy, but we can only handle so many issues at a time.

I have a very patient client in New Jersey (I never though I'd say "patient" and "New Jersey" in the same sentence") who ordered a lot of custom elements in a basic expert advisor. Most of the complications arose from the fact that I had to remotely access his computer with LogMeIn to do the programming. His indicator only has one license. Purchasing a second for the expert advisor programming was not economical.

The requirements to remotely access the computer and the amount of custom code turned a simple project into a complicated one. The way I addressed the issue was to remove almost all of the custom components and to replace them with code from our usual template. Now that the customer sees that the "strategy" stuff works, he found it much easier to write a checklist of bugs to fix. More importantly, seeing critical components of the code working reinforced his confidence in the company's programming ability.

Although he remained patient throughout the debugging process, I could hear the flagging confidence in his voice before we switched gears. Changing the direction of the plan showed him that the EA actually does work; it's the little pieces and how they fit together that are the problem. Of equal importance was the fact that he felt confident in my ability to deliver the results that he wants.

The consumer gets full credit for releasing control of the debugging process, even when he wasn't entirely comfortable doing so. The approach of papering over the custom steps with pre-programmed template code struck him as a step backwards. He nonetheless followed the programmer's lead, letting him drive the process with himself providing feedback where it was needed.

Both parties agree that we're once again heading in the right direction. The consumer sees obvious progress in his expert advisor. The programmer is able to manage the debugging process in a methodical, organized manner. Everyone is happy.

Realistic strategy development



The most realistic way to develop a strategy is to confess that you don't precisely know where you're going. You know it's likely to involve a certain indicator and that it either trends or ranges. The best way to get ready for the journey is to acknowledge in advance that it is indeed a journey. You more than likely will make changes, most of which you cannot expect.

It's 100% certain that something is going to go wrong when you program your first project. It's your strategy, but it's really a two-man team that builds it. Make sure to pick someone that knows what do when problems come up.

Before you select your programming partner, be sure it's someone that you genuinely trust to get the project done. You absolutely want to find someone that provides excellent communication skills and knows the importance of a timely answer. Organizing the project and overcoming unexpected challenges assists everyone get back to their true desire of trading.