Design a Trading Strategy
http://bit.ly/LIEPdK
One binding aspect typifies 99% of the trading strategies that we develop. The finished product does not stay completely true to the initial design. All development projects go forward in one of two ways. You can either pursue a task from the peak to the bottom, or you can build from down to up. The former alternative represents the old way of thinking, especially within higher education. When professors assign homework, the requirements never change. The project remains unchanging. Reality hardly ever cooperates like that. Instead, people change their minds. They watch the work underway and decide that a minor tweak might dramatically change the outcome. The expert advisor programmer is forced to constantly accommodate to the shifting goal posts. I repeatedly tell clients that they will alter their minds about a number of the rules during the process. Many stand firm that they will not. The clients do, naturally, predict that the conditions will work. Then, the rules surely change for nearly all of them. Theory goes out the window. The traders ascertain the real issues that expert advisors grapple with in the market. Coders created a new methodology to adapt to the regularly shifting rules. It's called agile development. This issue does not only take place with Forex traders. It also happens to businesses developing web sites, database programmers saving data, and in effect any project that involves human beings. People are prone to changing their minds. It's our condition. Agile development is the programmer's acknowledgement that getting upset at clients for changing their minds is not practical. The agile blueprint segments a project into time periods with an arranged list of goals. The crew decides which goals are most important and achievable within the allocated window. The window starts and everyone rushes to create as much code as possible. Everyone regroups after 2-6 weeks to rank the progress and to transmit the updated version to the client. Most expert advisor tasks only span a few weeks, so an exact replication of the agile blueprint would not adjust very well with creating a trading strategy. We throw the strategy development approach on its head by assigning sorted goals with a cutoff of 1-2 business days. The goal is to expedite communication, which is inevitably the most difficult obstacle in this field. We also make the evolution less established to expedite things along. The speedy answers suggest a succession of yes/no responses. The customer either gets fired up that it works properly, or more presumably, feels that we did not interpret him correctly. The truthful goal of this strategy is to get the user away from going over the concept for the 1,000th time in the same, identical way. The previous explanation did not help the plan move along. Consumer comments from functioning software guides the programmer into comprehending the thought on his own without making the client feel like he's echoing himself. I like to think of it as the consumer 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 consumers 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 plan 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 project showed him that the expert advisor 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 notion 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 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 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 vision. 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 make a choice of your programming partner, be sure it's someone that you genuinely trust to get the task done. You definitely want to work with someone that offers excellent communication skills and knows the importance of a timely response. Organizing the vision and overcoming unanticipated challenges assists everyone get back to their true passion of trading. FAP Turbo Here!