How does software project complexity scale with lines of code?
Staff and schedule grow roughly in step with code size — but the security takeaway is that more lines means proportionally more bugs, and bugs are where vulnerabilities live.
| Size | Staff | Time | Lines of Code | Example |
|---|---|---|---|---|
| Trivial | 1 | 4-6 weeks | < 500 | Simple admin programs |
| Small | 1 | 1-6 months | 1,000-2,000 | Small commercial apps |
| Medium | 2-5 | 1-2 years | 10,000-50,000 | Warehouse management |
| Big | 5-20 | 2-3 years | 50,000-100,000 | Small operating system |
| Very big | 100-1000 | 4-5 years | 1,000,000 | Database system |
| Extremely big | 2000-5000 | 5-10 years | > 10,000,000 | Air traffic control |
What the numbers actually show: As code grows from hundreds to tens of millions of lines, staff and schedule scale up roughly in proportion — this is sub-exponential, closer to linear growth, not a runaway curve. The point isn't a precise math model; it's the direction: bigger systems need many more people over many more years.
Why this matters for security: Bug density (defects per 1,000 lines) is roughly constant across projects, so 10x more code tends to mean ~10x more bugs — and a fraction of every bug count is a security vulnerability. A 10-million-line system therefore carries far more latent vulnerabilities than a 500-line one, which is exactly why "keep it simple" and "minimize attack surface" are security principles, not just style advice.