【Development Log】How to design decisions not to build. Among 40 MT4 tool ideas, 7 were halted, evaluation criteria before implementation: 4 criteria
1. Purpose and prerequisites of this paper
At Semura Lab, an environment visualization tool for MT4 was planned with 40 proposals in total, originally 27 plus 13 more. The current breakdown is 29 completed, 7 canceled, and 4 on hold.
This paper focuses on the seven proposals that were canceled, organizing the grounds for deciding not to build them. It is written so that the discussion can also be read as a common pre-implementation evaluation approach for EA and tool development.
【Image:fig21_tool_triage.png】2. Records of the seven canceled proposals
The names of the seven proposals and the reasons for cancellation are shown in the following table.
【Image:tbl4_cancelled_tools.png】The reasons may seem diverse at first glance, but they can be categorized into four types when organized. Those that attempted to fill missing data with approximations, those with heavy setup work before introduction, those where even after completion there is no visible use case, and a generic type that only computes from input values. The following sections examine them in order.
3. Analysis of the cancellation reasons
3-1. Design to fill in unavailable data with approximations (No. 18)
No. 18, “Actual-slippage wiring indicator,” was conceived as drawing a line on the chart to connect the order price and the fill price. However, in MQL4 there is no way to later obtain the request price at the moment of order placement. The fill price remains, but the reference for comparison does not.
As an alternative, an approximate approach using the opening price of the 1-minute bar at order time was considered. But in this case, what is drawn is not the slippage itself, but a difference from another price. A tool that visualizes slippage would replace slippage with an approximation. Since the purpose and the means of measurement conflict, it was canceled.
If the target of measurement itself is substituted with an approximation, the meaning of the numbers cannot be explained to users. This is the core problem of this proposal.
3-2. Introduction and environment costs (Nos. 16 and 26)
No. 16, “Giant log file alert,” cannot reliably reach the log folder due to constraints in MQL4 file access. A tool that monitors a location that cannot be reliably reached cannot stand. Even if effort is spent to bypass the constraint, it was deemed not worthwhile.
No. 26, “Ping jitter monitoring meter,” cannot obtain a real network ping with only MQL4. Under the policy of not using DLLs, a pseudo-measurement using WebRequest() was considered. However, users must add the target URL to a allow-list on the MT4 side.
What we valued here is that procedures that burden the developer will burden the user as well. If the tool’s value is outweighed by heavy setup before use, it was not adopted.
3-3. Not contributing to decision making (No. 22)
No. 22, “Server time & candlestick countdown,” displays the server time and the remaining time until the next candle forms. After completing implementation and compilation checks, we re-examined “what is this good for.”
The intended use was to prevent premature entries while waiting for candles to close and to address discrepancies between server time and PC time. The explanation was reasonable. However, we could not concretely depict what a user would judge by looking at those numbers. It was canceled in a completed state.
3-4. Generic calculation type vs. actual data aggregation type (B2–B4 and B1)
The additional proposals B2 (weighted moving averageEntry price), B3 (loss streak simulator), and B4 (lot calculation based on risk %) are of a type that computes answers from input values. B4 was rejected before implementation, and B2 and B3 were also not adopted. A function that merely calculates from input numbers did not find a justification to be offered as a standalone tool.
In contrast, the other addition proposal B1 (currency exposure duplication checker) was adopted and completed. This aggregates real data from positions held to show bias toward the same currency. Decide whether to use real account data or have numbers entered from outside. This difference led to adoption vs. non-adoption.
【Image:fig22_cancel_reasons.png】4. Four criteria for pre-implementation evaluation
From the above cases, four questions to check before implementation are organized.
(1) Can what you want to measure be acquired as is? If not, can the measurement objective be met by approximation?
(2) Are you asking users to pre-configure settings or change environments?
(3) By looking at that number, what will the user decide?
(4) Are real account/terminal data being used? Could external calculators substitute?
(1) corresponds to No. 18, (2) to Nos. 16 and 26, (3) to No. 22, and (4) to B2–B4 and B1. All of these are questions that can be answered before starting to write code.
As a usage strategy, you could first list the items that you cannot answer out of the four. If approximation only reaches your goal in (1), consider narrowing to a use case that can be satisfied with approximation. If user operations are required in (2), decide beforehand whether those operations are acceptable. If you get stuck in (3) and (4), re-evaluate whether there is a reason to release as a standalone tool at all.
5. Decisions to stop after implementation
No. 22 was canceled after implementation. Given the invested effort, it’s disappointing, but releasing a tool that users cannot use would damage product trust.
However, the question in (3) should have been verifiable before implementation. Whether you can articulate “what decision the numbers are for” during planning is valuable to incorporate into the evaluation process.
6. Implications for EA validation
The approach of using No. 18’s “substitute the opening price of the 1-minute bar” as an approximation overlaps with the structure of EA backtesting. Backtests also construct an ideal environment by interpolation to approximate reality.
There are problems where approximation is allowed and where it is not. Replacing the central measurement with an approximation changes the meaning of the results. Of the four design flaws cited by the Lab, the fourth—the gap between test environment and real world—is precisely this structure. The development of tools and the validation of EAs ultimately converge on the same core question.
7. Conclusion
We, Semura Lab, completed 29 of 40 proposals. At the same time, we decided not to build seven of them. Recording why we did not build those proposals clarifies the design criteria for what remains.
Do not substitute with approximations. Do not burden users before use. Be able to describe the judgments behind the numbers. Use real account data. The lab will release only those that satisfy these four points.
For design decisions and validation regarding EAs and tools, please consult the General Counseling Desk.