Chapter 6 — Calculus II
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Compounding"]
N2["6.2 Decay models"]
N3["6.3 Linear versus exponential"]
N4["6.4 Using the models"]
N5["6.5 Honest fit"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Compounding"]
N2["6.2 Decay models"]
N3["6.3 Linear versus exponential"]
N4["6.4 Using the models"]
N5["6.5 Honest fit"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Compounding]
|
v
[6.2 Decay models]
|
v
[6.3 Linear versus exponential]
|
v
[6.4 Using the models]
|
v
[6.5 Honest fit]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) use series and growth models to reason about compounding effects; (2) model decay of unpatched versions in a user base; (3) compare exponential and linear models; (4) interpret model fit honestly.
6.1 Compounding
When each component brings its own dependencies, the total can grow like a geometric series. If every package added brings, on average, 0.8 new transitive packages, adding one direct dependency adds 1 + 0.8 + 0.64 + ... = 1/(1 − 0.8) = 5 packages in expectation. This simple sum explains why a small decision can enlarge the attack surface far more than expected.
The series converges only when the average is below one; at one or above, each addition could bring an ever-growing tree, which in practice is limited only by the size of the ecosystem. Kwame uses the figure as a reminder, not a forecast: before adding a dependency, the team asks what it brings with it, and looks at the actual transitive list rather than the package's own size.
6.2 Decay models
After Coastline releases a fixed version of its mobile ticket app, users update gradually. If 10% of the remaining old installations update each day, the share still on the old version after t days is 0.9^t: about 35% after 10 days and 4% after 30. This exponential decay model helps plan how long old server-side support for the vulnerable version must continue.
The model assumes each remaining user is equally likely to update on any day, which is the assumption the next comparison tests. Real users do not behave that way.
6.3 Linear versus exponential
Kwame fits both models to the real update data from the last app release. The exponential model fits the first two weeks well but overestimates updating later, when the remaining users are those who rarely open the app. Neither model is perfect; he reports both and the range they imply.
A linear model, which assumes a fixed number of users update each day, fails in the opposite way: it predicts everyone will have updated by a certain date, which never happens. Reporting a range between the two models is more honest than choosing the one that gives the most convenient answer. The lingering tail of rare users is what security planning must cover.
6.4 Using the models
The models inform two decisions: whether to force updates for security fixes, and how long to keep compatibility code. A forced update shortens the tail but annoys riders whose phones are old.
The decision weighs exposure against cost. If a flaw lets someone tamper with tickets, a forced update after a few days may be justified; if the risk is minor, a prompt is enough. Compatibility code kept for old versions is itself a risk, since it preserves paths that the fix closed elsewhere, so its removal date is planned from the model's tail estimate.
6.5 Honest fit
A good fit on past data does not guarantee future behaviour; holidays, app store delays and phone models change patterns. Kwame states the model's assumptions in every chart caption.
Kwame also keeps the gap between prediction and outcome in view. If the model predicted 4% unpatched and reality showed 7%, he records the difference and adjusts the next forecast, rather than quietly refitting so the old prediction looks right. Captions such as 'assumes 10% of remaining users update daily; app-store review delays not modelled' tell readers when not to trust the chart.
Worked example
For the template fix, the server-side part is deployed at once, so the decay model applies only to the mobile app, which embedded a copy of the affected rendering code. Kwame predicts 4% of installations still unpatched after 30 days under the 10% daily model; actual data shows 7%. Coastline decides to show an update prompt after day 14.
Synthetic case. Update rates and app data are synthetic.
Errors and limits
Series and decay models simplify behaviour; validate them against observed data before relying on them.
Exercises
- EX016 — Expected packages. With branching 0.8, how many packages does one direct dependency add in expectation? Rubric: 3 = 5; 2 = partial; 1 = wrong; 0 = none.
- EX017 — Decay values. What share remains after 10 and 30 days at 10% daily updating? Rubric: 3 = ~35% and ~4%; 2 = one; 1 = vague; 0 = none.
- EX018 — Prompt decision. Why did Coastline add an update prompt at day 14? Rubric: 3 = observed 7% above predicted 4%; tail long; 2 = partial; 1 = vague; 0 = none.
Synthesis
Series and decay models make compounding and slow updating visible, within honest limits.
Continue studying — chapter 06 of 50
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →