loading...
running...
How to use
Pick a preset or move the sliders: demand, team size per stage, work content, quality and pressure. Crates are work items: blue is clean, red carries a hidden bug that only Review or Test can catch, amber has been reworked. Watch which queue grows, then fix it. Try: (1) Balanced team, then drop the testers to 1 and see the Test queue explode while utilisation hits 100%. (2) Too many cooks: add developers and watch capacity fall in the Brooks graph. (3) Kanban WIP limit: lower the cap and compare lead time with Little's estimate. (4) Death march: raise the pressure and watch the bug rate and tech debt climb. Drag to orbit, wheel to zoom. Space pauses, R resets.
The 3D factory was built in Blender 5.2 headless with baked PBR textures and exported as a Draco GLB; the crates, workers and barrels are instanced copies of three Blender prototypes. Quality defaults to High, use the button or ?q=low for a lighter render.
The science
The simulator treats a software team as a network of queues. Work items (features) arrive at random, wait, are worked on by a limited number of people and move on to the next stage. Because the maths of queues is exact, you can check the model against textbook formulas.
Queues. Each stage is a multi-server queue (M/M/c when the variability is exponential). With arrival rate λ, service rate μ per person and c people, the utilisation is
ρ = λ / (c μ), stable only if ρ < 1
For one server the mean time in system is W = 1 / (μ - λ), which explodes as ρ approaches 1: at 95% utilisation an item spends 20 service times in the system. For c servers the Erlang-C formula gives the probability that an item must wait, C(c, a) with a = λ/μ, and
W = C(c, a) / (cμ - λ) + 1/μ
Little's law. For any stable system, regardless of distributions, the average number of items in the system equals throughput times average time in system:
N = λeff · W
This is why a WIP limit works: capping N caps the lead time W = N / throughput. The grey dashed curve in the lead-time graph is N / throughput computed live; it follows the measured lead time.
Brooks' law. Adding people adds communication channels, n(n-1)/2 of them. If every channel costs a fraction κ of one person's time, the capacity of n developers is
C(n) = n · (1 - κ(n-1)/2) / tdev, dC/dn = 0 at n* = 1/κ + 1/2
Beyond n* a bigger team delivers less. The model includes only the communication cost; Brooks also described the training cost of newcomers, which is not modelled here. The efficiency is floored at 15% to stay positive.
Quality loop. Each change carries a defect with probability p. Review and Test catch a defective item with probabilities eR and eT and send it back for cheaper rework (half the work, a third of the defect risk). The probability that a defect finally escapes to production is
F = p q + p (1-q) F', F' = p' q / (1 - p'(1-q)), q = (1-eR)(1-eT), p' = 0.3 p
Pressure and debt. Schedule pressure s speeds developers up by s but multiplies defect probability by 1 + 1.5(s-1) and adds tech debt. Each escaped defect also adds debt. Debt slows developers by 1/(1 + D/80) and raises defect probability by 1 + D/150. Refactoring spends a share of dev time to pay the debt down at 4 points per developer-day per unit share.
Checks. In the panel the same engine runs textbook set-ups with a fixed seed: M/M/1 against 1/(μ-λ), M/M/3 against Erlang-C, Little's law on the same run, the escaped-defect fraction against the closed form above, and the numerical optimum of Brooks' capacity against n*.
Simplifications. The time unit is days and one item is one unit of work. People are identical, service times are exponential, Erlang-4 or deterministic, hand-offs cost nothing, and there are no weekends or holidays. The debt and pressure coefficients are plausible round numbers, not fitted to a data set. This is a teaching model of flow, not a prediction tool for a real project.