Simulations as Abstractions

Running a real experiment can be slow, expensive, or dangerous. Crashing an actual car costs the car. Watching real traffic for a year costs a year. A simulation sidesteps all that by building a simplified model in software: it keeps the few factors that matter for the question being asked and throws out everything else. That throwing-out is not laziness, it is the whole point. A model that included every detail of reality would be as complicated as reality itself, and just as hard to run or understand.

Take a traffic intersection. A full simulation could track weather, driver mood, tire tread, pedestrian phones. A useful one might keep only three rules: cars arrive at some average rate, a light cycles between red and green on a timer, and cars leave the intersection only on green. Run that forward and you get an answer to a narrow question, like how long the average queue gets. Every factor left out — rain, a stalled car, a jaywalker — is a piece of the real world the simulation is betting does not change the answer much.

That bet can be wrong. If a left-turn lane turns out to back up traffic in ways the three-rule model never captured, the simulation's prediction quietly stops matching reality, because the detail that mattered was never in the model. This is why simulations sit next to real testing rather than replacing it in this unit's bigger picture: they are fast, cheap tools for exploring an idea or narrowing down a design, but the abstraction that makes them fast is also exactly what can make them wrong.