In 1987, Fred Brooks observed that adding engineers to a late software project makes it later. He published this as Brooks’s Law. It was not a new observation — project managers had noticed it for years. But naming it changed how the field talked about it. Instead of arguing about whether it applied in this specific case, teams could ask: what aspect of Brooks’s Law is operating here, and what can we do about it?
That is the function of named laws in engineering. They do not tell you what to do. They tell you what constraints and tendencies to expect, so you can design with them rather than against them.
The sixteen laws are grouped by type, because the type determines how to use them. Mathematical constraints cannot be circumvented — you work within them. Empirical observations are tendencies that can be managed — you mitigate them. Design principles are advice — you apply judgment about when they apply.
Knowing the type of a law is as important as knowing the law itself. A team that treats Hofstadter’s Law as a mathematical constraint will be paralysed. A team that treats Amdahl’s Law as an opinion will build systems that violate physics.