Advanced Software Engineering Simulator: Delivery Pipeline, Queues, Little's Law and Brooks' Law

Presets

Live readouts

Graphs

Work in progress per stage (items)

Lead time vs Little estimate N / throughput (days)

Throughput (items/day) vs demand (blue)

Escaped defects (%) and tech debt

Brooks' law: developer capacity vs team size

Numerical checks

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. Space pauses, R resets.

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) / t_dev, 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 e_R and e_T 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-e_R)(1-e_T), 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.