The Laws of Software Engineering: A Reference Guide

This article compiles 56 essential laws and principles that influence software systems, team dynamics, and professional decision-making. It covers a broad spectrum of topics ranging from technical design patterns like DRY and SOLID to psychological effects like the Dunning-Kruger Effect. The collection serves as a reference for developers and managers to better understand the predictable patterns and pitfalls of the software industry.

Key Points

Software architecture is often a reflection of the communication structures within the organization that created it.
System complexity should be managed by evolving from simple, working systems and avoiding premature optimization or over-engineering.
Project management must account for human factors, such as the fact that adding more people to a late project often makes it later.
Technical quality is a continuous process of leaving code better than it was found and managing the inevitable accumulation of technical debt.
Effective decision-making requires recognizing cognitive biases and applying mental models like Occam's Razor or the Pareto Principle.

Sentiment

The community engages enthusiastically with the topic but is deeply skeptical of treating these principles as universal laws. There is strong agreement that software engineering principles are valuable but dangerous when taken as dogma. The dominant sentiment is that experience and context matter far more than any single maxim, and that the hardest skill is knowing when to break which rule. The discussion skews toward seasoned practitioners sharing hard-won lessons, with a notably cynical tone toward developers who hide behind pithy quotes to avoid thinking critically about their design decisions.

In Agreement

These laws serve as useful reference points and conversation starters for software engineering teams, even if imperfect
Conway's Law is consistently validated by real-world experience — organizational structure inevitably shapes system architecture
The collection helps codify tribal knowledge that experienced engineers learn through hard-won experience
Having a catalog of principles provides common vocabulary for discussing engineering tradeoffs
Many of these laws capture real tensions (simplicity vs. flexibility, speed vs. correctness) that engineers face daily

Opposed

The laws contain so many internal contradictions that you can cherry-pick whichever one justifies your position, making the collection less useful as actual guidance
Most of these 'laws' are misunderstood and misapplied in practice — premature optimization being the most egregious example — causing more harm than good
SOLID principles encourage premature abstraction and enterprise-style code bloat that makes codebases inscrutable
Postel's Law has been shown through bitter experience to be actively harmful for API design, as lenient input acceptance creates undocumented dependencies
Calling these 'laws' gives them undeserved authority — they're context-dependent heuristics at best and should not be treated as universally applicable
Many important principles are missing (Goodhart's Law, Curly's Law, POSIWID) while some included ones are outdated or only applicable to specific paradigms