Chapter 12 — Probability and statistics
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Patch latency"]
N2["Lab — patch latency"]
N3["12.2 Reading the result"]
N4["12.3 Skew"]
N5["12.4 Choosing measures"]
N6["Why the tail matters"]
N7["Visualising"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Patch latency"]
N2["Lab — patch latency"]
N3["12.2 Reading the result"]
N4["12.3 Skew"]
N5["12.4 Choosing measures"]
N6["Why the tail matters"]
N7["Visualising"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Patch latency]
|
v
[Lab — patch latency]
|
v
[12.2 Reading the result]
|
v
[12.3 Skew]
|
v
[12.4 Choosing measures]
|
v
[Why the tail matters]
|
v
[Visualising]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) summarise patch latency with mean, median and spread; (2) recognise skew; (3) choose meaningful measures.
12.1 Patch latency
Patch latency is the days from an update's release to its installation on a device. Aisha collects it for the last monthly update on all 45 laptops.
The data come from the management server's update report, which records the release date and the install date for each laptop. Aisha uses the install completed after restart, not the download date, so a pending restart counts as not yet installed. All 45 laptops have both dates for this update, so no laptop has to be counted as unknown.
Lab — patch latency
"""Summarise synthetic patch latency (days from release to install) for 45 laptops (stdlib only)."""
import statistics
days = [3, 4, 4, 5, 5, 5, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 9, 9, 10, 10, 11, 12, 12, 13, 14, 14, 15, 16, 18, 19,
21, 22, 25, 28, 30, 33, 35, 41, 47, 52, 60, 68, 75, 88, 104]
print(f"laptops {len(days)}, mean {statistics.mean(days):.1f}, median {statistics.median(days)}, max {max(days)}")
print(f"within 14 days {sum(d <= 14 for d in days)}/{len(days)}, over 30 days {sum(d > 30 for d in days)}")
Run with python3 lab_latency.py. Verified output:
laptops 45, mean 22.4, median 12, max 104
within 14 days 26/45, over 30 days 10
12.2 Reading the result
The mean is 22.4 days, the median 12 and the maximum 104. 26 of 45 laptops installed within 14 days; 10 took over 30 days.
Twenty-six of 45 is about 58%, and ten of 45 is about 22%, so more than one laptop in five took over a month. Rerunning the lab also shows that the 35 laptops at or under 30 days have a mean of about 11.5 days. The ten slowest laptops alone lift the fleet mean from about 11.5 to 22.4 days. Gareth checks the 104-day laptop first and finds it is the laptop kept in a drawer, which is switched on only occasionally and then installs whatever is waiting.
12.3 Skew
A few very late laptops pull the mean far above the median. The distribution is skewed, so the median describes the typical laptop better and the tail count describes the problem.
The lab's numbers show the skew directly: the median, 12 days, sits close to most laptops, while the mean, 22.4 days, sits above 32 of the 45 values. The longest delay, 104 days, is more than eight times the median. Aisha shows the sorted list to Gareth, because a single list makes the shape clearer than any one summary number.
12.4 Choosing measures
Bramley adopts two measures: share within 14 days and count over 30 days.
The first measure, 26 of 45 within 14 days at the baseline, tracks how quickly most laptops are patched. The second, ten laptops over 30 days, tracks the tail where the risk sits. Neither depends on the mean, so one laptop at 104 days cannot hide an improvement elsewhere, and Gareth can recalculate both from the same monthly report. Both measures can be checked against a target: at least 90% within 14 days, and the tail count falling month by month towards zero.
Why the tail matters
The ten laptops taking over 30 days are where risk concentrates. If a critical vulnerability is exploited widely within a few weeks of a fix, those ten remain exposed. Focusing on the tail gives Bramley a manageable list rather than a vague average.
Aisha lists the ten and finds common factors: six are home workers rarely on the VPN, three have full disks and one is the laptop in a drawer. Each factor suggests a fix.
Visualising
A simple sorted bar chart of days per laptop makes the tail visible to managers.
Repeat
The measure is repeated monthly for each update cycle.
Interpreting the tail
The mean of 22.4 days hides a long tail: ten laptops took over 30 days. Aisha looks at those ten individually and finds the three causes listed above: home workers rarely on the VPN, full disks and the laptop left in a drawer. The median of 12 shows that most laptops are fine. Fixing the tail, not the typical laptop, is where effort pays off.
Worked example
Gareth's old report said "average 22 days", suggesting a uniform delay. Aisha shows that most laptops patch within two weeks and a tail of ten causes the problem, which points to specific devices.
Synthetic case. Synthetic.
Errors and limits
A mean alone hides tails.
Exercises
- EX034 — Lab figures. Give mean, median and max. Rubric: 3 = 22.4, 12, 104; 2 = two; 1 = one; 0 = none.
- EX035 — Tail. How many laptops took over 30 days? Rubric: 3 = 10; 2 = partial; 1 = vague; 0 = none.
- EX036 — Measures. Which two measures did Bramley adopt? Rubric: 3 = share within 14 days, count over 30; 2 = partial; 1 = vague; 0 = none.
Synthesis
Use medians and tails for skewed data.
Continue studying — chapter 12 of 40
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →