← Blog ·

Systematic Trading is Not Gambling — It's Engineering

Most people confuse algorithmic trading with speculation. Here's how I think about it as a software architect: hypothesis, test, deploy, monitor.

Martin Fournier · February 15, 2026 · 3 min read

title: "Systematic Trading is Not Gambling — It's Engineering" excerpt: "Most people confuse algorithmic trading with speculation. Here's how I think about it as a software architect: hypothesis, test, deploy, monitor." category: "Trading"

The Misconception

When I tell people I do algorithmic trading, the reaction is usually one of two things:

  1. "Isn't that just gambling?"
  2. "You must be using AI to predict the market."

Both are wrong. And understanding why they're wrong is the foundation of systematic trading.

Trading as Engineering

A trading strategy is a hypothesis. It says: given conditions X, outcome Y has a measurable probability of occurring.

Like any hypothesis in software engineering, it needs to be:

  • Defined clearly — what are the exact entry and exit conditions?
  • Tested rigorously — on historical data (backtest) and unseen data (forward test)
  • Deployed carefully — with position sizing, risk limits, and monitoring
  • Reviewed continuously — markets evolve, strategies decay

This is not gambling. Gambling is making a bet without measurable edge. Trading systematically means you don't deploy a strategy until you've verified the edge exists.

My Process

1. Strategy Discovery

I use StrategyQuant X for automated strategy discovery. It uses genetic algorithms to generate and test thousands of strategy variations across different markets and timeframes.

The output isn't a finished strategy — it's a candidate hypothesis.

2. Robustness Testing

A backtest is necessary but not sufficient. A strategy that fits historical data perfectly is likely curve-fitted — it will fail on new data.

I apply several robustness checks:

  • Walk-forward analysis — test on rolling windows of unseen data
  • Monte Carlo simulation — randomize trade order and measure outcome distribution
  • Parameter sensitivity — small changes in parameters should not collapse results

If a strategy passes all three, it earns the right to be forward-tested.

3. Forward Testing (Paper Trading)

Before any real money, the strategy runs live on a paper account via Interactive Brokers API. I compare live performance to backtest expectations.

Divergence is a signal to investigate, not to panic. Markets change, and some divergence is expected.

4. Live Deployment

Once I'm satisfied, I deploy with strict risk controls:

  • Maximum position size per trade
  • Maximum portfolio heat (total risk at any given time)
  • Maximum drawdown before the strategy is paused

5. Monitoring

I built custom dashboards that track P&L, drawdown, and execution quality daily. Surprises in live trading almost always trace back to execution issues or changing market conditions.

The Emotional Component

The hardest part of systematic trading isn't the technology — it's trusting the system when the inevitable drawdown comes.

Every strategy has drawdowns. The question is whether the drawdown is within the expected range (normal) or outside it (something is broken).

Having clear, pre-defined rules for each scenario is what separates a systematic trader from someone who just has a system until the losses start.

Software Thinking Applied to Markets

The parallels to software development are striking:

| Software | Trading | |---|---| | Feature hypothesis | Strategy hypothesis | | Unit tests | Backtests | | Integration tests | Forward tests | | Production deploy | Live trading | | Monitoring & alerts | Performance dashboards | | Refactoring | Strategy optimization |

If you're a developer looking to explore systematic trading, start with this mental model. The tools are different. The discipline is the same.


I'm happy to discuss strategy development, backtesting frameworks, or the IB API. Get in touch.