Chapter 1 — Calculus I
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Rates of change"]
N3["1.3 Accumulation"]
N4["1.4 Reading graphs"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Rates of change"]
N3["1.3 Accumulation"]
N4["1.4 Reading graphs"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The case]
|
v
[1.2 Rates of change]
|
v
[1.3 Accumulation]
|
v
[1.4 Reading graphs]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) use rates of change to describe how software risk grows; (2) model accumulation of unpatched exposure over time; (3) read graphs of change; (4) connect calculus ideas to the course case.
1.1 The case
Kwame Asante is an engineering student at the fictional Ridgeway Institute of Technology. Through his five-year course he works with the fictional Coastline Transit, whose web app "ticket-web" sells bus and ferry tickets. His industry mentor is Ingrid Solberg, Coastline's lead engineer. In Kwame's first term, Coastline found that a copy of its build output on an internal mirror did not match the published digest, and that a template library in ticket-web had a published flaw affecting output escaping. Neither caused harm, but both made Ingrid ask how her team could know, at any moment, that what runs is what was built and that its parts are safe. Kwame's course returns to these two questions throughout.
1.2 Rates of change
A derivative measures how fast something changes. If ticket-web's dependency count grows from 40 to 160 over four years, the average rate is 30 new components per year. The instantaneous rate tells you whether growth is speeding up: a steepening curve means review effort must grow faster too.
Kwame compares yearly increments rather than the average alone. If the count rose by 15, 25, 35 and 45 in successive years, the average is still 30, but the increments themselves are growing, which means the review workload is accelerating. A team that plans for the average will fall further behind each year.
1.3 Accumulation
An integral adds up a rate over time. If a vulnerable component is present for t days at a risk rate r(t), the accumulated exposure is the area under r(t). Shortening the time to upgrade reduces this area directly; this is why later chapters measure remediation days.
The area grows with both height and width, so a severe flaw left for a few days can matter as much as a mild one left for weeks. Kwame treats time as the lever the team controls: it cannot choose when advisories appear, but it can choose how quickly fixes reach production.
1.4 Reading graphs
Kwame plots weekly open advisories for ticket-web. The slope after a big framework upgrade is negative for six weeks, then flattens. A flat line at a non-zero value means advisories arrive as fast as they are fixed.
The negative slope shows the upgrade cleared a backlog, because many old advisories were fixed at once. The flattening tells a different story: the team is now keeping pace but not gaining ground. To bring the line down further, Kwame suggests the team either fixes faster or reduces how many components can receive advisories in the first place, for example by removing dependencies nobody uses.
1.5 Limits
Calculus models assume smooth change; real advisories arrive in jumps. Models are guides for reasoning, not precise forecasts.
A single large advisory can arrive overnight, and a whole group of components can be fixed in one upgrade, so the real curve is a staircase rather than a smooth line. The models still help compare options, such as weekly versus monthly releases, as long as conclusions are stated as comparisons and not as predictions. Kwame labels every chart with its assumptions, so readers do not mistake a sketch for a measurement.
Worked example
Kwame models exposure for the template flaw: published on day 0, patched in ticket-web on day 9, deployed on day 11. With constant risk rate, exposure is proportional to 11 days. If deployment had waited for the monthly release (day 30), exposure would be nearly three times larger. Ingrid uses the comparison to argue for faster security releases.
Synthetic case. Ridgeway Institute, Coastline Transit, ticket-web and all figures are synthetic.
Errors and limits
Risk rates are rarely known; the model compares options rather than giving absolute risk.
Exercises
- EX001 — Growth rate. What is the average yearly growth from 40 to 160 components over four years? Rubric: 3 = 30 per year; 2 = partial; 1 = wrong; 0 = none.
- EX002 — Exposure area. How does faster upgrading reduce accumulated exposure? Rubric: 3 = shrinks area under risk curve; 2 = partial; 1 = vague; 0 = none.
- EX003 — Flat line. What does a flat non-zero advisory line mean? Rubric: 3 = arrivals equal fixes; 2 = partial; 1 = vague; 0 = none.
Synthesis
Rates and areas give a language for growth and exposure in software.