Software Evolution & Systemic Laws

Abstractions about empirical regularities and structural pathologies governing long-lived software systems and teams — growth and stability dynamics (Lehman's laws, no silver bullet, ninety-ninety rule), structural-health diagnostics (cohesion, god object, bus factor), and platform-scale displacement (Atwood's law, Bell's law).

16 abstractions in this family — domain-specific abstractions that sit near one another in structural-signature space (k-means over structural-signature embeddings). Each is shown with its short description.

• Atwood's Law — Jeff Atwood's observation that any application that can be written in JavaScript eventually will be — naming the dynamic by which a general-purpose default's accumulated ecosystem advantage colonises a specialist's niche once it crosses a threshold, regardless of the technical gap.
• Bell's Law of Computer Classes — The empirical generalization that roughly every decade a new, cheaper, smaller class of computer emerges on a new platform technology and displaces the prior class from volume dominance — a discrete threshold crossing derived from continuous Moore scaling.
• Bus Factor — The minimum number of team members whose sudden simultaneous loss would halt a project — a per-capability count of how many people could take a subsystem, credential, or relationship over tomorrow, exposing where tacit human knowledge is dangerously concentrated.
• Cohesion (software / module-level) — Grade how tightly the responsibilities inside one code module turn around a single articulable purpose — from coincidental to functional — reading nameability, isolation-testability, and low-risk replaceability straight off the level.
• Discoverability Failure — Diagnose why a working feature goes unused: the capability exists and functions perfectly, but no signal on any surface the user samples announces it, so the user's option set is bounded by the visible interface and the feature is operationally nonexistent.
• Fallacy of One Administrator — Reason about a deployed system as though one authority governs every node it depends on, when it actually crosses many independently-governed administrative domains — so failures concentrate at the unmodeled seams between them.
• God Object Anti-Pattern — Diagnose a maintenance mess as concentrated rather than diffuse: one class or service accumulates outlier fan-in and fan-out to become the integration hub, collapsing modularity so all change-cost, comprehension, and new features funnel through that single node.
• Interface segregation principle — The SOLID rule that clients should not depend on interface methods they do not use — decompose a fat interface into role-specific ones sized to each consumer's usage footprint, so a contract change's blast radius is read off the boundary rather than the call graph.
• Jailbreak Adaptation — The dynamic in which a distributed community collectively probes a deployed AI system's policy boundary, turns each bypass into a shared public good, and so out-iterates the deployer's update cycle — making the contest a rate race no single patch can win.
• Lehman's law of conservation of familiarity — Hold the mean change shipped per release of a long-lived software system roughly constant, because the producer and consumer communities have a bounded capacity to absorb novelty, and overdrawing it forces a corrective contraction.
• Lehman's law of conservation of organizational stability — Observe that a long-lived software organization's long-run work rate returns to a band set by structural parameters no matter how you push the local dials — staffing, hours, pressure — so durable throughput gains require restructuring, not loading.
• Lehman's law of continuing growth — State that a long-lived software system must continually expand its functional content to retain users, because satisfaction is judged against a rising competitive reference point — adaptation alone holds fitness constant while rivals grow past it.
• Lehman's law of self regulation — Treat a long-lived software project as a closed feedback loop that self-regulates around an operating point, so single-node pushes are absorbed and only structural changes to the loop durably relocate its release-size, cadence, and defect-density distributions.
• Ninety-Ninety Rule — The first 90 percent of the code takes the first 90 percent of the time and the last 10 percent takes the other 90 percent — a deadpan warning that nominal-progress metrics measure only the estimable bulk-work population and never the non-parallelizable, heavy-tailed completion tail.
• No Silver Bullet — Brooks's thesis that no single innovation will yield an order-of-magnitude gain in software productivity within a decade, because past gains already mined the accidental complexity (tool-and-environment friction) and the binding constraint is now essential complexity — difficulty inherent in the problem that no tool can dissolve.
• Touch Target Size — The HCI rule that interactive elements be large and well-spaced enough for the operating population's worst-case input precision to hit reliably — grounded in Fitts's Law and codified as platform minimums like 44pt or 48dp.