Laws of Software Engineering

Source: lawsofsoftwareengineering.com | Author: Dr. Milan Milanovic | Published: 2025 (exact date not listed; copyright 2026) Category: methodology | Credibility: medium

Executive Summary

• A curated, non-academic reference site cataloguing 56 software engineering principles across seven domains (Teams, Planning, Architecture, Quality, Design, Decisions, Scale), accompanied by a paid book with 63+ entries.
• The author is a credentialed practitioner (PhD Computer Science, Microsoft MVP, 20+ years industry experience) but the site is a solo compilation, not peer-reviewed research.
• Several laws (Conway’s, Brooks’s, Hyrum’s, CAP Theorem) have meaningful independent empirical support; others (Dilbert Principle, Zawinski’s Law) are observations or folk wisdom with no rigorous validation, yet all receive equivalent presentation weight.

Critical Analysis

Claim: “Conway’s Law — Organizations inevitably design systems that mirror their own communication structure”

• Evidence quality: peer-reviewed
• Assessment: This is among the best-supported claims on the site. A 2025 ECIS study, MIT/Harvard Business School research, and Microsoft’s Vista study all provide independent quantitative support linking team communication structure to architectural modularity. Martin Fowler’s documentation further consolidates evidence. The claim is directionally correct and widely reproduced empirically.
• Counter-argument: The inverse application (“Inverse Conway Maneuver” — restructure teams to achieve target architecture) is harder to execute than stated; organizational inertia means the causal arrow often runs both ways, and team restructuring introduces its own coordination costs. The law also does not account for tooling changes (async collaboration, remote-first orgs) that decouple team topology from communication structure.
• References:
  • A Quantitative Study on Conway’s Law (ECIS 2025)
  • Empirical research supports Conway’s Law — Allan Kelly
  • Conway’s Law — Martin Fowler

Claim: “Brooks’s Law — Adding manpower to a late software project makes it later”

• Evidence quality: case-study
• Assessment: Substantially supported. A dataset from 7,200 software projects confirms diminishing returns from late-stage headcount additions. NASA’s SEL documented 3–6 month ramp-up times that compound schedule pressure. A system dynamics model confirms the mechanism (training overhead + increased communication paths) rather than just the surface observation. Widely validated.
• Counter-argument: The law has known failure modes: it treats all engineers as fungible, ignores specialization (adding one rare expert vs. ten generalists), and does not apply when the bottleneck is non-human (e.g., waiting on hardware, regulatory approval). A 2025 reframing by Jamie Lord notes modern AI-assisted onboarding may reduce ramp-up time, potentially shifting the break-even point.
• References:
  • Brooks’s Law — Wikipedia (with meta-study references)
  • Brooks’s Law: Why Adding More People Makes It Later (Jan 2025)

Claim: “Hyrum’s Law — With sufficient users, all observable behaviors of a system become dependencies regardless of the documented contract”

• Evidence quality: case-study
• Assessment: Well-grounded in Google’s internal experience at scale. Hyrum Wright observed this pattern internally around 2011–2012 when core library changes broke downstream projects relying on undocumented timing or error message behavior. The law is operationally validated at Google’s scale and widely accepted by API maintainers. The claim is accurate for large public APIs.
• Counter-argument: The law applies weakly to small-user APIs and internal services with disciplined consumers. It also overstates inevitability — strong versioning discipline (semantic versioning, deprecation windows, API changelogs with explicit behavioral guarantees) can significantly delay or avoid the collapse of the contract/behavior boundary. Newer APIs designed with behavioral contracts from the start (gRPC with protobuf schemas, OpenAPI strict mode) are less susceptible.
• References:
  • Hyrum’s Law — hyrumslaw.com
  • Hyrum’s Law and API Design — Axway

Claim: “CAP Theorem — A distributed system can only guarantee two of: Consistency, Availability, Partition Tolerance”

• Evidence quality: peer-reviewed
• Assessment: CAP is a mathematically proven theorem (Brewer 1998, Gilbert & Lynch 2002 formal proof). The underlying claim is correct. However, its practical utility for system design is widely criticized as insufficient: partitions are rare in normal operation, yet CAP forces a binary framing that ignores latency entirely. PACELC (Daniel Abadi) is the more operationally useful extension that addresses the normal-operation trade-off between latency and consistency.
• Counter-argument: Presenting CAP without PACELC, or without distinguishing “P is always present in a distributed system, so the real choice is C vs. A during partitions,” can mislead system designers into treating it as a three-way trade-off when it is effectively a two-way one. The site’s framing is accurate but incomplete for practical decision-making.
• References:
  • Beyond CAP: The PACELC Theorem — DEV Community
  • CAP Theorem — Wikipedia (Gilbert & Lynch proof reference)

Claim: “SOLID Principles — Five guidelines (SRP, OCP, LSP, ISP, DIP) for maintainable OO design”

• Evidence quality: anecdotal
• Assessment: SOLID is widely adopted and taught, but empirical evidence of its measurable impact on software quality is limited. A 2025 arXiv paper found that modern AI frameworks apply SOLID selectively, making intentional trade-offs. Critics (Dan North on SRP being “vague”) and practitioners note that strict SOLID compliance often leads to over-engineering in small codebases. There is no rigorous RCT-style study showing SOLID-adherent codebases have lower defect rates.
• Counter-argument: SOLID principles are most valuable in large OO codebases with many contributors and long maintenance horizons. For small teams, scripting contexts, functional languages, or data-pipeline code, strict SOLID adherence actively harms productivity (premature abstraction). The site presents SOLID as universally applicable without this critical scoping caveat.
• References:
  • Evaluating SOLID in Modern AI Frameworks (arXiv 2025)
  • Defense of SOLID Principles — NDepend

Credibility Assessment

• Author background: Dr. Milan Milanovic — PhD in Computer Science, Microsoft MVP for Developer Technologies, 20+ years industry experience across finance, banking, energy, and telco, 20+ academic papers with h-index 11 on Google Scholar, and a Substack newsletter reaching 400,000+ subscribers. The author is a credible practitioner-communicator, not an academic researcher in software engineering principles.
• Publication bias: Independent practitioner compilation. The site is not a vendor blog and has no commercial interest in promoting specific tools. However, it does sell a companion book and monetizes via newsletter. The bias risk is toward accessibility and broad appeal over academic rigor — all 56 laws receive similar weight regardless of evidence quality.
• Verdict: medium — The site is a well-researched, useful reference by a credible author. Several laws (Conway’s, Brooks’s, CAP, Hyrum’s) are grounded in empirical research or formal proofs. Others (Zawinski’s Law, Dilbert Principle, Cunningham’s Law) are folk wisdom presented without the same evidentiary caveat. The compilation format flattens epistemic quality differences across entries.

Entities Extracted

Entity	Type	Catalog Entry
Conway’s Law	pattern	link
Brooks’s Law	pattern	(subsection of software-engineering-principles)
Hyrum’s Law	pattern	(subsection of software-engineering-principles)
CAP Theorem	pattern	link
Technical Debt	pattern	link
SOLID Principles	pattern	link
Software Engineering Principles (collection)	pattern	link