The Principle: Half of Development Time Belongs to Objectives
System development is normally imagined as a technical activity: choosing indicators, writing rules, running backtests, and tuning parameters. The principle discussed here proposes a different time allocation. At least half of the total development effort should go into defining objectives before, and alongside, any technical work. Objectives are treated not as a formality but as the input that makes every later decision meaningful. The reasoning is structural rather than motivational. A trading system is a set of rules that converts market data into position decisions, and every one of those rules encodes a preference. How much leverage to use, how far to place a stop, how often to trade, how long to hold, which instruments to trade, and how much capital to risk per idea are all choices. Without a stated objective, those choices have no criteria behind them. The only remaining benchmark becomes the backtest result, which measures what happened historically rather than what the trader actually needs. When objectives are defined first, they act as a reference frame. They determine which metrics matter, which trade-offs are acceptable, and which strategies are disqualified before any code is written. A trader who knows the maximum drawdown that can be tolerated, the hours available per week, and the intended use of the capital has already narrowed the design space considerably. The remaining technical work becomes a search inside a bounded region rather than an open-ended hunt for a strategy that looks impressive in a chart. The principle is easy to overlook because goal-setting produces no visible artifact. There is no equity curve, no indicator panel, no optimized parameter set. It feels like delay. In practice, the notes describe it as the foundation on which every other design decision rests, and the part of the process most often skipped.
The Default Habit: Jumping Straight into Signals and Parameters
The common sequence in system development begins with a market observation or a familiar tool. A trader notices that RSI divergences appear to precede reversals, or that a moving-average cross seems to capture trends, and immediately moves to specification. Entry conditions are written, exits are added, and the strategy is tested. When results disappoint, parameters are adjusted and the cycle repeats. This sequence is attractive because it produces immediate, measurable feedback. Changing a lookback period from 14 to 20 generates a new number, and that number feels like progress. Goal definition produces no such feedback, which makes it psychologically harder to sustain. The problem is that parameter optimization requires an objective function. Without an explicit one, the implicit objective becomes maximizing whatever the backtest reports, usually total return or a profit factor. That single implicit goal then drives every parameter choice, including leverage and position size, which are precisely the parameters that determine whether the system is survivable. A configuration that scores well on a historical sample may require a risk level far beyond what the trader would accept in live conditions, and the mismatch is invisible because it was never measured. A second consequence is overfitting. When the objective is a single aggregate performance number, the search tends toward configurations that fit noise in the sample. The notes frame this as a symptom of missing goals: with a properly defined objective, criteria such as maximum acceptable drawdown, minimum trade frequency, or maximum holding period act as constraints that rule out fragile configurations early, before optimization has a chance to exploit them. Finally, jumping straight to signals makes evaluation circular. The trader cannot say whether a strategy is good, only whether it scored higher than the previous attempt. That is a ranking, not an assessment.
