EA Craftsman’s EA Course [004] Surprisingly Tough? How is EA developed?

EA Development Process

EA developers, when they come up with an idea or method for a trade, put the idea into words, break it down to the logical level, turn it into a program, and translate it into the language that computers can understand, i.e., machine language.

When creating something, I think this is true in general, and in the world of EA development it starts with phases like system planning, requirements definition, and specification definitions—where ideas like “it would be nice to have an EA that makes this kind of profit” are considered.

What is created at that time is the specification document.

In the case of EA, this corresponds to instructions and requirements regarding behavior, such as “enter under these conditions. If it becomes this, exit.”

On smartphones, it would be something like “If you hold down the power button for more than 1 second while the power is off, it should power on. However, if the remaining battery is less than 4%, it should not power on and should display a warning.”

If you get this wrong, all subsequent work will have to be redone, so this is the phase that requires the most effort. By the way, ‘effort’ here means costs such as personnel and time.

Once that specification is decided, the next step is to translate it into a logical level. This is the so-called design phase.

As with all phases, we use diagrams and figures as much as possible so that anyone viewing it will interpret it the same way.

The worse design documents are filled with explanations in words. Japanese, in particular, has many vague expressions. If you outsource that to overseas, you can expect many bugs to come back.

To prevent this, we make use of diagrams (such as relationship diagrams or flow charts) and tables (state transition tables, matrices, etc.) and design them so that anyone can interpret them the same way.

In basic design, we build the overall framework of functions, and in detailed design we fill in the contents of each function.

After the design is finished, it’s finally time for programming... and though some say this is the main part, this phase is actually the easiest and does not require much time or cost.

Because the thinking ends at the design phase; after that, you just translate what is written in the design document into a programming language.

Since it is a straightforward task, this phase is already mechanized, and it is sometimes entrusted to auto-coding or automatic generation apps.

Now, after programming is finished, we translate into the machine language that computers can understand. This is called compiling, and we use a compiler to do it.

Computers Have No Intelligence

Huh? Languages like C or MQL aren’t understood by machines?

No, they aren’t. Computers operate only on 0 and 1, more precisely on states of on and off, and voltages being high or low.

That’s obvious. They aren’t living creatures, so even though we call it machine language, they don’t truly understand words.

That’s why we replace programming languages with information in 0s and 1s, and the computer reads that and adjusts voltages up or down. Which of 0 or 1 is interpreted as on depends on the design.

In this way, EA developers translate trading methods and ideas into programs and proceed to the right-hand phase of this V-model, “Testing.”

We test not only whether the created program enters and exits under the expected conditions, but also whether it stops functioning at any point during operation.

A Long Path

If an unexpected behavior, i.e., a bug, is found, we fix it and re-test. This work is called debugging.

A bug came to be called that because a bug somehow got into the computer and caused a circuit to short, resulting in unexpected behavior.

Ideally we would like to make bugs zero, and of course we aim for that, but even when actually operated, unforeseen events may occur.

In case that happens, we also build safeguards to prevent worst-case scenarios, such as trading in an unexpected lot size. This is called a fail-safe. Literally, “safe even if a failure occurs.”

It’s like the automatic stopping devices in cars or elevators; even in case of failure or abnormal events, the system is designed to operate on the safe side so that it never reaches a dangerous state.

There is something similar called foolproof. Fool means a fool, and proof means to withstand; foolproof means preventing worst-case outcomes even if a fool operates it.

With those tasks completed, you finally reach the familiar backtesting stage. It was quite a long road, wasn’t it?

If the backtest does not produce satisfactory results, we start over from the planning stage.

In this way, the planning and backtesting are looped over and over; the bad EAs are culled, and only those with satisfactory results become visible to everyone.

■ My Developed EA Concept and Operational Policy

EA Craftsperson’s EA (Three Arrows) is here