Is FOREX trading simple? No, it’s not simple. But it can be if you understand a few basic concepts of not only the market, but of yourself and how you could best interact with that market.

All my life I've dealt with complexity: I have a B.S. in Physics, I had a 33 year career as a senior web based business applications software engineer, and spent 40 years as a real estate investor.

And I've dealt with the complexities of life itself in my over 50 years now in the martial arts.

All of that background enabled me to be an expert at abstracting out the key elements of complex systems into simple components.

Of note is that to this post, I have a companion video of the same title: Is FOREX Trading Simple? that puts all of this together from a different view point.

If you've come from watching that video, then press on here. However, if this is your starting point, I might suggest that you read through this before watching the video. Or, if you want, you can skip to the bottom of this post to watch that video now.

I mention my background not to impress you, but rather to show you how simple it is to filter out all of the noise of a problem, or of some life event, and find simple solutions.

Trust me when I say that doing this is not difficult. However, you do have to have the ability to step back from an issue, and objectively determine exactly what the problem is that needs to be solved.

For example, if your car suddenly starts spewing smoke from under the hood: would you be able to determine whether the engine was on fire, or if it had simply overheated? Or would you be standing over on the curb, wringing your hands, and spewing epitaphs at it?

That's not to say that you would have any clue as to how to fix the problem, but only that you have the ability to look at some complex event, and see what that problem is.

You can't solve a problem you can't identify.

Complexity is not the problem.

Complexity is the result of some system operating within the context of whatever the rules are that govern that system.

If you've lived on the tundra for your whole life, and then get on a bus traveling through the Los Angeles metro highway system you'd probably have a heart attack at the seeming total confusion around you.

But there's order in all of that confusion — if you're familiar with driving, and the rules of the road. You don't have to concern yourself with the other 10,000 cars around you. All you have to do is follow the same rules everyone else is to get to your destination.

The currency market is complex. Very, very complex. And so are we as human beings. Now, take that complex market, and try integrating a trading plan — also a complex entity — with your complex human imbalance of hope, fear, and greed.

How does that picture look? Maybe like a Jackson Pollock painting?

A great deal of this post will be taken up doing the software analysis and design of a simple framework for an airline flight reservation system. This will be done to show a methodology that can be used across many design analysis problems, and I will demonstrate this by showing how that methodology can be used in currency trading to decompose the complex issue of trade entry.

Bear with me through this discussion because the solution path I'll be laying out is not only simple, but directly applicable to the process of resolving the complexities of trade entry, for example, in currency trading.

I've dealt with — and become conversant in — problem resolution in over 30 different complex business domains. To name a few:

• Order entry and inventory control tracking
• Municipal government operations software
• Airline flight reservations and booking systems
• Warehouse operations
• Remote sales force client administration
• Product distribution
• Transportation operations systems analysis
• . . . .

One of the more complex of those is airline flight reservations and booking systems. Let's take that one as an example of how I would go about programming a solution.

So, what's the problem implicit within the domain of 'airline flight reservations and booking systems'? Well, it's simply taking desired travel information from a user, and matching that up with available flights.

What's complex about that? Well, the system would have to know all of the destination airports from every initiating airport, with many of those requiring connecting flights, and those connecting flights could be either continuation flights on the selected airline, or on what are called 'code share' partner airlines. Whew! Where do you even start analyzing that mess? And that's just one tiny issue in the over all scope of creating an airline reservation for a customer.

Well, at its core the real task is to first understand that the user is going to input information into the application that needs to be sent to another application which will retrieve all of that flight information, and send it back. What's important to note at this stage of the application development is that it is not important to worry about matching the user request for flights, for example, that go out between 8:00am and 10:00am that will provide a meal service, and allow them to bring their dog.

The crux of all of that is recognizing that the primary information that the user needs to send is some date. That's it. Whatever else the user is going to be required to send is secondary to what date of travel they want to go on.

So, all I do as the developer of this system is to create a simple web page with a date input box and a 'Submit' button. It'll look like this:

Bobs Airline Flight Reservation System Request Screen

Stupid simple, yeah? And so is the computer code behind such a screen, a very simple screen....

And later, you can start to spruce up the screen so it has some appeal....

What next? Well, the next step is to have the application accept a user input submitted date.

I'll call this the BAController (for Bobs Airline Controller). So, through the magic of the internet HTTP communication protocol, when I click the 'Submit' button, the application will attempt to send this data to the BAController which is located on some server at the airline headquarters.

What do you think will happen if all I've deployed of the application is this screen when the user hits that Submit button?

Well, it's not going to work. You'll get a big error message on the screen that says something to the effect that no application, i.e. no 'object', was found out there to send the message to.

Now, this type of thing, i.e. knowingly leaving out building something until you absolutely need it, is part of a specific type of development process. Because you're writing code that will break, and then fixing it, the process is generally referred to as a 'Test First' approach. What this does is it prevents the developer from wasting time building stuff that might not be needed until later, and more importantly not distracting them from the specific simple task they are supposed to do.

I'm going to show you a very basic Java programming language representation of the bare bones of this BAController object so you can see how simple it is. Now, bear in mind this would not work over the internet; things are a bit more involved than this simple code!

/**
 * Main application controller for Bob's Airline
 */
public class BAController {
  public String createReservation(String resDate) {
    String message = "Reservation request for: " + resDate;
    return message;
  }


  public static void main(String[] args) {
    BAController con = new BAController();
    String resDate = "05/05/21";
    String reply = con.createReservation(resDate);
    System.out.println(reply);
  }
}

There are 2 parts to this BAController:

1. Method: main
2. Method: createReservation

A 'method' simply represents some discrete piece of work you want the 'object' to do.

A 'main' method allows you to run the application, and in this case: it simulates an internet request from a customer's browser to the BAController method 'createReservation'. Things are, obviously, more involved than this, but it is the way that the programmer can simplify the development process by using this 'main' method to simulate what would otherwise be a fairly complex internet communication between the customer's browser and the airlines server.

In a real application, the internet HTTP protocol will look for this 'createReservation' method on the BAController, and pass it the text string resDate, which in this case is the reservation departure date the customer types into the screen which in turn happens to be '05/05/21'.

You're obviously reading this blog post way past this '05/05/21' date, so the obvious issue then becomes that the airline shouldn't even waste any time processing such a request. It should inform the user that they need to type in some future date.

And that's all well and good, but remember, I'm only building the absolute simplest application structure that I can to begin the development process. Once I have a complete solution path established, I just go back through the code adding complexity in as needed. But that process is easy because the path is all that needs to be followed.

I'm only going to take this application to the next step as all further steps will be identical: build the absolute simplest framework to ultimately get to the point where the entire application structure is complete.

In order to get the significance of this next step, you will, unfortunately, have to fully understand the overall flow of this application up to this point so you can see the relevance of those next steps. So, let me quickly walk you through this first framework:

1. The method 'main' is where the application itself starts. In this case, the main method is simulating a customer request from a browser to display all of the available departing flights on 05/05/21. All of the code in that main method simply prepares the BAController to receive that date into its method 'createReservation'.
2. The method 'createReservation' shows that it is expecting to receive a string of information and will reference that information from within the method as 'resDate', for 'reservation date'.
3. Method 'createReservation' accepts that data, and then sends a message (i.e. 'reply') back to the 'main' method which will say: "Reservation request for: 05/05/21"

So, I'm going to change the 'createReservation' method on the BAController to call another object, BAFlightFinder. In applications programming, the controller simply organizes the work to do, but delegates each step of that work off to other objects. It does this by establishing which object it wants to pass information to. This is done in the code:

BAFlightFinder flightFinder = new BAFlightFinder();

The BAController then calls the flightFinder method findFlightsByDate(resDate), passing it the departure date the customer requested way back on the browser input screen (that was simulated in the BAController's 'main' method).

As you can see, the BAController is expecting the BAFlightFinder method findFlightsByDate to return a message containing departing flights on that requested departure date, resDate.

public class BAController {
  public String createReservation(String resDate) {
    BAFlightFinder flightFinder = new BAFlightFinder();
    String message = flightFinder.findFlightsByDate(resDate);
    return message;
  }
 }

Obviously then, I'm going to need to write this BAFlightFinder object, and put a findFlightsByDate(resDate) method on it that returns a message....

/**
 * Bobs Airline flight finder. From the input
 * departure date, return all flights leaving
 * on that date.
 */
public class BAFlightFinder {
  public String findFlightsByDate(String resDate) {
    String message = searchForFlights(resDate);
    return message;
  }

  private String searchForFlights(String resDate) {
    String message = "No flights for date: " + resDate;
    return message;
  }
}

Okay, so the resDate comes into the BAFlightFinder's findFlightsByDate(String resDate) method.

Notice then that yet another method searchForFlights(String resDate) is called. This is just done to better organize the work that an object will do.

The test is simply to get to this first unit of work for the BAFlightFinder. And to simplify the whole thing, I just have this method return the message "No flights for date: 05/05/21".

I hope the code didn't confuse you, and that you are able to see how this very complex business requirement can be represented very easily by understanding exactly what the problem to solve is, and then writing the absolute least amount of code to solve it.

Currency trading is a complex problem, just as is developing an airline flight reservation system. In showing how to create a simple approach to achieving a solution to a customer being able to find a flight, in currency trading we're trying to determine if we should enter a trade or not.

So, let's look at currency trading the same way I indicated I had to analyze the development of that airline flight reservation system: I had to start with determining what the core problem was. In that instance, it was to have a customer be able to get a list of flights on a certain date.

When you have that price chart up on the screen in front of you, what are you looking for? You're looking to see if there is a trade entry opportunity, right? Yup.

Okay, well what's the first thing you're going to want to know? It's what direction the price is moving in, and if that direction is the same as some higher time frame. If that's the case, then it would indicate a higher probability that price on your time frame will continue in that direction. That's called 'confirmation'.

V1: Trade Entry Analysis Rules

1. Confirm price direction from higher time frame.

Great. What would be next? You'd probably want to know if there was a support or resistance boundary close to the current price. If there was, then you might not want to enter the trade. So, that's another rule to add.

V2: Trade Entry Analysis Rules

1. Confirm price direction from higher time frame.
2. Confirm price not close to support or resistance zone.

Given that there are no close support or resistance zones to potentially block price, does the price itself appear to have enough strength ‐ whatever that is ‐ to move enough pips to warrant the risk of entering. Add it to the plan.

V3: Trade Entry Analysis Rules

1. Confirm price direction from higher time frame.
2. Confirm price not close to support or resistance zone.
3. Does price have the strength to move 15 pips.

Note that in the plan I quantified the rule of strength to that capable of price moving 15 pips.

Should I have done that?

No. That would be an incorrect parameter to the rule at this stage of the development of the system. And that is why the background color is different for that rule.

By quantifying the price move to 15 pips adds a second variable to the rule. The first variable is what we mean by 'strength'. This term has not been identified as yet. Nor should it. But to now add another variable, pip distance, complicates this rule by a factor of 4.

How does adding a second variable to the rule complicate it 4 times? In mathematics, this is called a permutation. A permutation "...determines the number of possible arrangements in a set when the order of the arrangements matters." [Ref: Corporate Finance Institute.]

Let me explain. Rule Variable 1 is strength, and I'll denote that by referring to it as 'A'. Rule Variable 2 is pip distance, and I'll denote that by referring to it as 'B'. Thus, our 2 rule variables are A and B.

So, the question is: How many ways can you order those 2 variables? The answer is that there are 4 ways:

Permutations Of 2 Variables

1. A
2. B
3. AB
4. BA

Don't do this as it complicates the system. Let's therefore restate V3 of the rules:

V3: Trade Entry Analysis Rules

1. Confirm price direction from higher time frame.
2. Confirm price not close to support or resistance zone.
3. Does price have the strength to move enough pips to warrant the risk of entering.

I could go on for a few more rules, but I think you get the picture.

Once the full analysis is done, you then go back to each rule, and fully flush it out in the same manner that I explained how the software engineer will go back and iterate over their previously written code to fill in details and complexity.

This was immediately answered with: "No, it’s not simple. But it can be if you understand a few basic concepts of not only the market, but of yourself and how you could best interact with that market."

A great deal of the post was taken up doing the software analysis and design of a simple framework for an airline flight reservation system. This was done to show a methodology that can be used across many design analysis problems, and I demonstrated this by showing how that methodology can be used in currency trading to decompose the complex issue of trade entry.

Video: Is FOREX Trading Simple?