Laws of Software & Systems

#wisdom#strategy#architecture

Laws of software and systems are empirical observations and axioms that describe how technology, organisations, and complex systems behave. For a Chief Technology Officer or engineering leader, these laws serve as vital mental models. Understanding them helps prevent systemic architectural failures, organisational dysfunction, and costly management mistakes.

Mapping the Laws

These laws generally fall into two categories: Organisational Dynamics (how teams and structures interact) and Systems & Complexity (how software and platforms evolve).

1. Organisational Dynamics

Conway’s Law

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." — Melvin Conway

  • Strategic Utility: If you have two separate teams building a single product, you will likely end up with two separate subsystems. To achieve a clean, modular architecture, you must first design team structures that mirror that desired architecture. This approach is known as the Inverse Conway Maneuver.

Martec’s Law

"Technology changes exponentially, but organizations change logarithmically." — Scott Brinker

  • Strategic Utility: While technical innovations emerge at a blistering pace, human organisations, cultures, and processes adapt slowly. CTOs must build modular system architectures and flexible operational models that allow the company to absorb new technology without constantly disrupting the entire organisation.

2. Systems & Complexity

Gall’s Law

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." — John Gall

  • Strategic Utility: Avoid massive, "big bang" rewrites or launching over-engineered monolithic architectures from day one. Build a simple, working Core MVP, validate it in production, and iterate incrementally to add complexity.

Goodhart’s Law

"When a measure becomes a target, it ceases to be a good measure." — Marilyn Strathern (popularised by Charles Goodhart)

  • Strategic Utility: If you measure engineers purely on lines of code, code coverage, or velocity points, they will optimise their behaviour to hit those numbers, often sacrificing software quality or system reliability. Use metrics as diagnostic health checks, not as direct compensation targets.

Hyrum’s Law

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." — Hyrum Wright

  • Strategic Utility: Public contracts and documentation are not enough. As an API scales, clients will rely on undocumented quirks, timing characteristics, and side effects. CTOs must plan for migration friction whenever changing or upgrading widely used internal or external APIs.

Amdahl’s Law

Describes the theoretical limit of speedup in parallel computing when only a portion of the system can be parallelized. — Gene Amdahl

  • Strategic Utility: If 20% of your program is strictly sequential, the maximum speedup you can achieve—no matter how many parallel processors or resources you add—is 5x. This applies directly to business processes and engineering pipelines: identify the absolute sequential bottleneck before throwing resources at parallel efforts.

Law of the Instrument

"If the only tool you have is a hammer, to treat everything as if it were a nail." — Abraham Maslow

  • Strategic Utility: Technical teams often suffer from "Golden Hammer" syndrome, trying to solve every problem with the database, framework, or language they already know best, even when it is highly unsuited. Tech leaders must encourage broad, diverse problem-solving methodologies.

References

Internal

External

Created: June 9, 2026Last modified: June 9, 2026