One common element unites 99% of the trading strategies that we’ve developed. The final product does not match the initial design.
All programming projects proceed in one of two ways. You can either develop a project from the top-down, or you can build from the bottom up. The former option represents the old way of thinking, especially within the university system. When professors assign a project, the requirements never change. The assignment remains static.
Real life rarely cooperates like that. Instead, human beings change their minds. They see the work in progress and decide that a minor tweak might dramatically alter the outcome. The expert advisor programmer is forced to constantly adjust to the moving goal posts.
I always tell clients that they will change their minds about some of the rules during the process. Most insist that they will not. They do, after all, expect them to work.
Then, the rules inevitably change for most of them. Theory goes out the window. The traders discover the real issues that expert advisors face in the market.
Programmers developed a new methodology to accommodate the constantly shifting rules. It’s called agile development. This problem doesn’t only occur with forex traders. It also happens with businesses making web sites, database programmers storing information, and really any project that involves human beings. People are prone to changing their minds. It’s our nature. Agile development is the programmer’s acknowledgement that getting upset at people for changing their minds is not entirely reasonable.
The agile approach breaks a project into time periods with a ranked list of objectives. The team sorts out which objectives are most important and do-able within the allotted time. The period starts and everyone rushes to accomplish as much programming as possible. Everyone regroups after 2-6 weeks to evaluate the progress and to deliver the updated version to the client.
Most expert advisor projects only last a few weeks, so a precise copy of the agile approach would not fit very well with developing a trading strategy. We flip the strategy development approach on its head by assigning ranked priorities with a deadline of 1-2 business days. The goal is to facilitate communication, which is inevitably the most challenging obstacle in this field. We also make the process less formal to speed things along.
The quick turnarounds lead to a series of yes/no answers. The client either gets excited that it works properly, or more likely, feels that we did not understand him correctly. The honest goal of this approach is to get the user away from explaining the idea for the 1,000th time in the same, identical way. The last explanation did not help the project move along. Client feedback from working software leads the programmer into understanding the concept on his own without making the client feel like he’s repeating 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 clients 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 EA 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 client 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 project 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 client gets full credit for releasing control of the debugging process, even when he wasn’t entirely comfortable doing so. The idea 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 client 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 acknowledge that you don’t exactly 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 prepare 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 choose your programming partner, make sure it’s someone that you actually trust to get the job done. You ideally want to find someone that offers strong communication skills and appreciates the importance of a timely reply. Organizing the project and overcoming unexpected challenges helps everyone get back to their true passion of trading.