The program nobody wrote

A courier company needs to tell customers when their parcel will arrive. The dispatcher who has done the job for eleven years can look at an address and a parcel and say “about fifty minutes” and be right most of the time. Nobody has ever asked her to explain how. If you did, she would say something vague about traffic and the size of the box.

You have been asked to replace her with software. You could interview her for a week and try to write down her rules. Or you could take the eleven years of delivery records the company already has — distance, weight, time of day, minutes actually taken — and let a program work out the relationship for itself.

The second option is machine learning. It is not a different kind of computer or a different kind of intelligence. It is a different way of producing the logic inside a program: instead of a person specifying the steps, an algorithm derives them from recorded examples.

If you have come across predictive modelling, you have already met the same idea from the statistics side, where the emphasis falls on assumptions, inference and business framing. This course goes the other way: what the algorithm does mechanically, what its settings control, and how to build it in scikit-learn.

Task, experience, performance

The cleanest definition of machine learning is Tom Mitchell’s, and it is worth memorising because it forces you to be specific. A program learns from experience E with respect to some task T and some performance measure P, if its performance at T, as measured by P, improves with E.

Three things, all of which you must be able to name before you start:

  • The task is what you want predicted. For the courier: given distance and parcel weight, output the delivery time in minutes.
  • The experience is the recorded data. Past deliveries where you know both the inputs and the answer.
  • The performance measure is a number that says how wrong you are. For a time estimate, the average number of minutes you miss by.

If you cannot fill in all three slots, you do not yet have a machine learning problem. You have an interest in a topic. The most common failure in a first project is a vague task (“understand our customers”) with no performance measure attached, which means there is no way to tell whether anything is working.

Here is all three, made concrete:

import numpy as np
from sklearn.linear_model import LinearRegression
from sklearn.metrics import mean_absolute_error

# Experience: eight past deliveries.
# Each row is [distance in km, parcel weight in kg]
X = np.array([[2.0, 0.5], [5.0, 1.2], [9.0, 0.8], [12.0, 3.5],
              [15.0, 2.0], [21.0, 4.1], [26.0, 1.5], [30.0, 5.0]])

# The answers: minutes the courier actually took
y = np.array([14, 26, 38, 52, 60, 79, 90, 108])

# Task: learn a mapping from the two inputs to the minutes
model = LinearRegression()
model.fit(X, y)

print(model.coef_.round(2))       # [3.04 1.73]
print(round(model.intercept_, 2)) # 8.76

# Performance measure: average minutes off
print(round(mean_absolute_error(y, model.predict(X)), 2))  # 0.85

# A delivery the model has never seen: 18 km, 2.5 kg
print(model.predict([[18.0, 2.5]]).round(1))  # [67.8]

Two lines of that snippet do the learning: LinearRegression() chooses the shape of the rule, and .fit(X, y) finds the specific version of that shape which best matches the records.

The rule you never typed

Look at what came out. The model settled on roughly three minutes per kilometre, one and three-quarter minutes per kilogram, and about nine minutes of fixed overhead. That is a delivery-time formula. It is legible, it is defensible in a meeting, and you did not write it. It was extracted from eight rows of history.

That is the whole trick, and everything else in this course is a variation on it: richer shapes of rule, better ways of finding the right version, and better ways of checking whether the rule will hold up on parcels you have not seen yet. How the fitting actually happens — what “best matches” means and how the algorithm searches for it — is the subject of how machines learn from data.

Prediction is not understanding

One caution before you get attached to that formula. The model found that longer distances go with longer delivery times. It has no idea that distance causes the delay. If the records had happened to include a column for the colour of the courier’s jacket, and the courier who wore blue also happened to work the outer suburbs, the model would have learnt that blue jackets add forty minutes and would have been right on every historical row.

That is not a bug in the algorithm. The algorithm did exactly what it was asked: find whatever in the inputs tracks the output. It cannot distinguish a mechanism from a coincidence, because both look identical in a table of numbers.

The practical consequence is that a model is reliable for prediction under conditions like the ones it was trained on, and unreliable the moment you use it to decide what to change. “Deliveries would be faster if we bought red jackets” does not follow from the data. If you need to know what causes what — which is what most business decisions actually require — prediction accuracy alone will not tell you.

The three conditions a problem has to meet

Machine learning is not a general-purpose replacement for thinking. A problem is a candidate only if all three of these hold.

A pattern exists. There has to be a real relationship between the inputs and the answer. Longer distances genuinely do take longer. If you try to predict tomorrow’s lottery numbers from yesterday’s, no algorithm will help, because there is nothing there to find. A model given noise will still return a rule — it will just be worthless.

You cannot write the pattern down. If the relationship is something you can state exactly, state it exactly. Nobody trains a model to convert Celsius to Fahrenheit. Machine learning earns its cost when the rule is real but too tangled, too high-dimensional, or too personal to too many small factors for a human to specify.

You have data on it. Enough recorded examples, covering the range of cases you actually care about. Eight deliveries were enough for a demonstration. They would not be enough to run a business on, and they contain nothing at all about rain, lifts, or narrow lanes.

Miss any one of these and you should stop. Most abandoned projects failed on the third condition, and failed at the point where someone assumed the data existed because the company was large.

When machine learning is the wrong answer

Even when all three conditions hold, there are situations where a learned model is the wrong instrument.

The rule is prescribed rather than discovered. Tax bands, statutory notice periods, VAT, interest calculations. These are not patterns waiting in data; they are decisions someone made and wrote in a document. Learning them from examples would be slower, less accurate, and illegal to get wrong.

A single mistake is catastrophic. A model that is right 97% of the time is excellent for ranking search results and unacceptable for deciding whether a brake should engage without a hard safety envelope around it.

You need a full explanation for every decision, by law. Some models can be read as easily as the delivery formula above. Many cannot, and if a regulator requires a specific reason for every individual refusal, that constrains which models you are permitted to use.

It is a one-off decision. Machine learning pays for itself through repetition — thousands of predictions from one fitted model. For a decision you will make once, an afternoon of analysis beats a fortnight of engineering.

The honest position is that machine learning is a tool for a specific shape of problem: repetitive, pattern-rich, data-covered, and tolerant of being wrong occasionally. That shape covers an enormous amount of commercially useful work, which is why the field matters. It does not cover everything.

You can see the full parameter list for the estimator used above in the scikit-learn documentation for LinearRegression.

Key Takeaways

  • Define your task, your data and your performance measure before writing any code — if you cannot state all three in one sentence each, you do not yet have a machine learning problem.
  • Machine learning produces the logic of a program from recorded examples, so treat the fitted coefficients as the deliverable and read them the way you would read code someone else wrote.
  • Check that a real pattern exists, that you cannot simply write it down, and that you hold data covering the cases you care about, because failing any one of these means no algorithm will rescue the project.
  • Reject machine learning for prescribed rules, catastrophic single failures and one-off decisions, and reach for it when the same decision has to be made thousands of times.