Knowing When to Stop

Two decisions: when to kill a strategy, and when to kill the project. Both are made badly, in the same direction, for the same reason.

Killing a strategy

The asymmetry to guard against: you will want to kill working strategies during normal drawdowns, and keep broken ones out of hope. Both errors come from judging on recent P&L, which is the noisiest available signal.

Write kill criteria before deployment. Three categories:

Statistical. Live results fall outside the range the backtest implies. The rigorous version is a sequential test rather than a fixed threshold, because you're evaluating continuously:

import numpy as np


def cusum_monitor(live_returns_R: np.ndarray, expected_E: float,
                  sigma: float = 1.0, threshold: float = 5.0) -> dict:
    """
    CUSUM control chart for strategy degradation - standard SPC, applied to
    expectancy. Accumulates evidence that realised expectancy has fallen
    below the expected value, and signals when the accumulated shortfall
    exceeds a threshold.

    More responsive than waiting for a fixed trade count, and far more
    principled than reacting to the last few trades.
    """
    # Standardised deviation from expectation, with a small allowance (k)
    # so that ordinary noise doesn't accumulate.
    k = 0.5 * sigma
    deviations = (live_returns_R - expected_E) / sigma

    cusum = np.zeros(len(deviations))
    for i, d in enumerate(deviations):
        prev = cusum[i - 1] if i > 0 else 0.0
        cusum[i] = min(0.0, prev + d + k)  # accumulate negative excursions only

    breached = np.where(cusum < -threshold)[0]
    return {
        "cusum": cusum,
        "current": cusum[-1] if len(cusum) else 0.0,
        "breached_at_trade": int(breached[0]) if len(breached) else None,
    }

Structural. The mechanism you identified in Part III no longer applies. The forced seller found another route; the regulation changed; the counterparty you were being paid by left. This is the strongest kill signal available and it doesn't require any P&L evidence at all - if the mechanism is gone, the edge is gone, whatever the recent returns say.

Operational. The strategy requires more attention than it earns, or it depends on a venue you no longer trust.

Killing the project

Harder, because it implicates your judgement rather than a piece of code.

The honest calculation is opportunity cost, and for a working software engineer it's brutal. Five hundred hours is a substantial fraction of a year's discretionary time. Valued at what your professional hours are worth, that is a large sum, and it is being spent to attempt something with the base rates in Chapter 1.

That is not an argument against doing it. It is an argument for doing it deliberately, with a stated budget, rather than drifting into an indefinite commitment because stopping would mean the previous hours were wasted. Sunk costs are sunk. The only question is whether the next hundred hours are the best available use of that time.

Set the budget in advance, in hours and in money. Review it on a schedule. Renewing it consciously is a decision; failing to notice it has been exceeded is not.

What you keep either way

If you stop, you do not lose the substance of what you built:

• A rigorous approach to validating claims against noisy data.
• The instinct to ask how many things were tried before the reported result.
• Practical statistics - sample size, multiple comparisons, out-of-sample discipline - that transfer directly to A/B testing, performance analysis, model evaluation, and every other place where an engineer is handed a number and asked whether to believe it.
• A production system with real reliability constraints and genuine consequences for failure.

The methodology is more valuable and more durable than any particular strategy, and it is the part that cannot decay. The strategy might stop working next year. The habit of asking "what would have to be true for this to be noise?" will not.

A closing note

The honest summary of this book is that systematic trading is a domain where the median outcome is a loss, where being intelligent is table stakes rather than an advantage, and where the most common failure is not a lack of rigour but rigour applied to the wrong question.

If you proceed, proceed with a defined budget of time and money you can lose entirely, with kill criteria written before you start, and with the base rates from Chapter 1 held clearly in view rather than filed under "that won't be me."

And keep the notebook. Whatever else happens, the record of what you tried and what you concluded is the asset - because the alternative, an unrecorded sequence of impressions, is indistinguishable from having learned nothing.

End of Trading Systems for Software Engineers.