Software Evolution Laws & Code Smells

← Back to Domain-Specific Families

Abstractions about how software systems degrade or must adapt over time, dominated by Lehman's laws of software evolution (continuing change, increasing complexity, declining quality, self-regulation), paired with code-quality anti-patterns (Code Smell, God Object, Lazy Class) and aphorisms about accumulating complexity like Greenspun's Tenth Rule.

17 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.

• 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.
• Code Smell — Treat an observable feature of code as defeasible evidence of a deeper design or maintainability problem—not proof of a defect—so inspection triggers a context test and a refactoring hypothesis.
• 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.
• Dialectics — Contradictions drive change.
• 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.
• Greenspun's Tenth Rule — The aphorism that any sufficiently complicated C or Fortran program contains an ad hoc, bug-ridden implementation of half of Common Lisp — because features a language withholds do not vanish but migrate inside the program as defective re-implementations.
• Integrated Design — A design process jointly evaluates and revises coupled choices across specialties against shared whole-system goals.
• 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.
• Lazy Class — The code smell in which a class (or function, module, package) carries too little responsibility to justify the overhead it imposes — the defect living in the economy, not the behaviour, so a correct, clearly-named boundary can still be flagged when its carried value fails to clear its enumerable tax.
• 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 change — The empirical software-evolution law that an E-type system — one embedded in a moving real-world environment — must be continually adapted or it progressively becomes less satisfactory, because its fitness is relational (the gap between what the code does and what the world now requires) and that gap widens monotonically while the code stands still.
• 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 declining quality — Read software quality as the system's fit to its present environment rather than its intrinsic defect count, so an unchanged, bug-free release still degrades in the field as the surrounding world drifts away from the conditions it was built for.
• Lehman's law of increasing complexity — Observe that the structural, behavioral, and conceptual complexity of an evolving software system rises monotonically under unmanaged change — an entropy-positive default that only deliberate, non-feature restructuring can bend back down.
• 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.
• Software Entropy — Read a codebase's growing structural disorder as a predictable gradient under continuous modification: locally expedient edits flow toward the vast basin of working-but-disordered states, and order decays monotonically unless restoring engineering effort is continuously reinjected.