Tech • AI • Robotics • Game
Programming Laws Tier List | TheStandup
5/10TL;DR
A review of classic software engineering maxims ranked Conway’s Law and Hyrum’s Law as the most durable, while treating Brooks’s Law, Linus’s Law, and Hofstadter’s Law as far more context-dependent.
KEY POINTS
Conway’s Law led the rankings
Conway’s Law was treated as the strongest principle: systems tend to mirror the communication structure of the organizations that build them. In practice, that means separate teams often create separate data models, interfaces and workflows, forcing glue code and coordination layers between them. The law was framed less as a comment on org charts than as a rule about information flow: the slower communication becomes across people, teams or companies, the more product evolution concentrates inside those boundaries.
Microservices and micro frontends were cast as Conway effects
The discussion linked microservices and micro frontends to Conway-style constraints. These architectures can isolate blast radius and let teams ship independently, but they also reflect the reality that large organizations cannot coordinate every change tightly. That helps explain why patterns that may suit firms with thousands of engineers often become counterproductive when copied by smaller teams that could simply talk directly.
AI may not weaken Conway’s Law
Even with modern tooling, Conway’s Law was described as likely to remain durable. The same bottlenecks can emerge between software agents, compilers, services and evaluation loops if communication is slow or fragmented. The core claim was that uneven rates of information transfer create uneven rates of improvement, whether the actors are humans or machines.
Brooks’s Law drew skepticism
Brooks’s Law holds that adding manpower to a late software project makes it later. That idea was placed in a lower tier because it was seen as inconsistent rather than false: onboarding cost, knowledge transfer and added coordination can slow delivery, especially once a project is already slipping, but the result depends heavily on who is added and why. In some cases, a strong contributor can accelerate a struggling effort instead of delaying it.
Modern tooling has weakened some old assumptions
Part of the criticism of Brooks’s Law was historical. It emerged in an era of IBM System/360, assembly, and Fortran, when shared abstractions and developer tooling were limited. Today, engineers can learn codebases faster through standardized platforms, stronger documentation patterns and AI-assisted code search, although bespoke internal systems and poor documentation still remain common in large companies.
Moo’s Law captured institutional avoidance
Moo’s Law says an information retrieval system will not be used if getting the information is more painful than not having it. That idea resonated as a description of how teams avoid dashboards, reports or tests that reveal costly questions or politically inconvenient facts. The principle was treated as meaningful but not universal, since some engineers see such reports as useful backlogs rather than problems to hide from.
Eagleson’s Law split opinion
Eagleson’s Law says that after six months away, a programmer’s own code feels like someone else wrote it. The reaction was mixed. Some argued that AI tools now make re-entry much easier by reconstructing context quickly, while others said their own code remains easier to understand because their design habits and assumptions stay consistent over time, even when the code itself is flawed.
Linus’s Law was judged too vague
Linus’s Law, often summarized as “given enough eyeballs, all bugs are shallow,” was not rejected outright, but it was seen as too imprecise to rank highly. More knowledgeable contributors may increase the chance of reproducing and fixing a bug, especially in a large open-source community, but crowds can also create noise, false leads and conflicting diagnoses. The result was a view that the principle may be directionally true without being reliable enough to qualify as a strong law.
Goodhart’s Law was seen as highly relevant to engineering organizations
Goodhart’s Law says that when a measure becomes a target, it stops being a good measure. It was applied to engineering metrics such as AI token usage, startup-time improvements and output counts. Once compensation, rankings or executive pressure are tied to a number, teams can optimize the number rather than the underlying goal, creating behavior that looks productive while undermining product quality or long-term value.
Hyrum’s Law was another top-tier principle
Hyrum’s Law states that with enough users of an API, every observable behavior will be depended on by someone, whether documented or not. This was ranked at the top because it explains why even small implementation quirks become compatibility burdens. A cited example was Go changing long-standing for loop behavior only after years of hesitation, because too much real code had already come to rely on it.
Hofstadter’s Law was treated as too inconsistent
Hofstadter’s Law says things always take longer than expected, even after accounting for Hofstadter’s Law. It was considered less useful as a practical rule because software work often swings both ways: some tasks collapse in minutes, others expand for weeks. A more convincing observation was that work often stretches to fit the deadline available, rather than obeying a fixed law of delay.
CONCLUSION
The strongest laws were the ones that describe structural constraints and user behavior, not personal productivity. In this ranking, Conway’s Law, Hyrum’s Law, and Goodhart’s Law stood out as the most durable guides to how software systems and engineering organizations actually behave.
Ask a question