Programming Laws Tier List: Which Are Truths and Which Should Be Retired?

When Programmers Start Grading "Laws"

The programming world is full of "laws" named after people—from Conway's Law to Brooks's Law—written into textbooks, hung on conference room walls, and even used as the basis for technical decisions. But do they all really deserve the word "law"? In an episode of TheStandup podcast, several senior developers subjected these laws to a merciless Tier List ranking, and the results were surprising—some laws treated as gospel were relegated to the bottom, while some often-overlooked observations were elevated to the top.

This article walks through the core points of that discussion and adds some extended reflections: as AI coding tools become increasingly widespread, do these rules summarized decades ago still hold up?

S Tier: Conway's Law—More Universal Than You Think

More Than Just an Org Chart

The classic statement of Conway's Law is: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." Most people understand it as "team structure determines code structure"—for example, the team responsible for checkout and the team responsible for the shopping cart will produce two different user data models, then barely stitch them together with glue code.

But one developer in the discussion offered a deeper interpretation: Conway's Law essentially describes information transfer efficiency. Information travels fastest within a single brain, slightly slower between two people in conversation, slower still across teams, and slowest across companies. Therefore, every time a communication boundary is added to a system, evolution across that boundary slows down, while parts that don't need to cross the boundary can iterate faster.

Micro-frontends Are Just a "Patch" for Conway's Law

Following this logic, architectural patterns like microservices and micro-frontends aren't simply meant to make development easier—they're about reducing the communication costs imposed by Conway's Law. In large companies with engineering organizations of thousands, chaos is the norm—you can't possibly know everything that's happening, so you can only use architectural isolation to shrink the "blast radius" and let each team deliver at its own pace.

This also explains a common misconception: certain architectural practices at Google make sense internally because Google has the corresponding organizational scale and information transfer costs; small teams copying them only add complexity—after all, the colleague at the next desk is the one writing the checkout code, and shouting over is far more efficient than building a microservices architecture.

Still Valid in the AI Era

Most intriguingly, the discussants believe Conway's Law isn't even limited to human organizations. When multiple AI agents collaborate, the communication links, testing steps, and compiler feedback between them create "slow connections," and these bottlenecks cause the system to evolve at different speeds in different modules—exactly like human organizations. Conway's Law was therefore rated S tier: it's foundational enough and durable enough.

Overrated Laws: Brooks's Law and Hofstadter's Law

Brooks's Law: People ≠ Speed

"Adding manpower to a late software project makes it later." This observation from The Mythical Man-Month was rated C tier or lower on the Tier List, on the grounds that it's unreliable.

Counterexamples abound: sometimes adding the right person immediately revives a project; sometimes adding a bad person drags down a project that was on schedule. The discussants pointed out that this law was born in the IBM System 360 era, when the development environment was vastly different from today. With AI tools today, new members understand codebases far faster than before—you can have AI walk through repository history, explain the reasoning behind a technical choice, and context that once took weeks to build can now be 80% acquired in minutes.

More critically, the root cause of many late projects isn't engineering itself: sales promised a two-year project in three months, and at that point adding people only puts more people in the conference room arguing about architecture rather than making code go faster.

The Mythical Man-Month is a software engineering classic published in 1975 by Frederick P. Brooks Jr., based on his experience leading System/360 OS development at IBM. The book debunks the myth of the "man-month" as a unit of work—the notion that people and time are simply interchangeable—and emphasizes that "conceptual integrity" requires a small number of architects to lead. Brooks's Law is precisely a rebuttal to the intuition that "more people means faster." Its core mechanisms include communication costs growing quadratically with headcount, new members needing to learn context, and the indivisibility of tasks. However, the law's original context was large monolithic systems, waterfall development, and an era lacking modern collaboration tools; today modular architectures, continuous integration, and AI-assisted codebase comprehension are all changing the marginal cost of "adding people."

Hofstadter's Law: Uncertainty Is the Truth

"It always takes longer than you expect, even when you take into account Hofstadter's Law." This law was rated "unreliable" because its predictive power is too weak—sometimes something you expect to take a month is done in 30 minutes; sometimes a change you think is simple is still being debugged a month later.

The discussants proposed an alternative observation: the truly stable rules may be "work expands to fill the time available" (Parkinson's Law), and "no matter when the deadline is set, things always get done around then."

Hofstadter's Law was proposed by Douglas Hofstadter in his 1979 book Gödel, Escher, Bach, originally stated as: "It always takes longer than you expect, even when you take into account Hofstadter's Law." It's a self-referential humorous observation rather than a quantifiable predictive model. Its value lies in reminding people of the systematic optimism bias in planning, but its flaw lies precisely there too: it's nearly impossible to falsify, since any overrun can be attributed to "not accounting for this law." The complementary Parkinson's Law (work expands to fill the available time) offers a more actionable management perspective—compressing unnecessary expansion by setting tight deadlines. Together, they better explain why project timelines always converge near the deadline.

Old Laws Being Rewritten by AI

Jason's Law: After Six Months, Code Is Like a Stranger

"After six months away, your own code looks like someone else wrote it." This law was rated F tier in the AI era—because now it might not even take six months, and you never even looked at the AI-generated code.

But an interesting counterpoint emerged in the discussion: one developer said returning to your own code is often easier than reading someone else's, not because of code quality but because of consistency of underlying assumptions. You know you wouldn't use certain constructs, you know your habitual abstractions—these default settings greatly reduce cognitive load. Only when your coding style changes drastically (say, suddenly trying a purely functional style) does the "can't recognize my own code" situation arise.

Jason's Law is not a formal academic term but an empirical observation circulating in the programming community, often stated as "any code you haven't looked at for six months looks like someone else wrote it." It reflects the fragility of human memory and context dependence: when writing code, you hold a lot of underlying assumptions that aren't explicitly recorded—why this data structure was chosen, why that API was bypassed, which edge cases have been considered. This "tacit knowledge" decays rapidly after leaving a project. After AI-assisted programming became widespread, the law's applicability has been challenged: on one hand, AI-generated code may never have been carefully read by a human, so there's nothing to "forget"; on the other hand, AI can quickly comb through repository history and commit messages to help rebuild context, partially offsetting memory decay.

Goodhart's Law: The Moment a Metric Becomes a Target

"When a measure becomes a target, it ceases to be a good measure." This law received an A-tier rating, but the discussants made an important qualification about its scope.

In programming, many metrics are "hard"—startup time, first render time—these measure real things and are hard to distort. But when metrics are indirect and vague, problems arise: if a company measures "AI tokens consumed per person per month" to drive AI tool adoption, employees can simply run an idle loop at night to inflate the numbers. If performance is tied to "number of PRs that reduce startup time," engineers might deliberately introduce performance regressions first, then fix them in batches to rack up PR counts.

The discussants extended this with the Netflix case: once "user watch time" became the core metric, the bar for content quality could be continuously lowered in exchange for more viewing—the metric was hit, but the product's original value proposition may have been eroded.

Goodhart's Law is named after British economist Charles Goodhart, who noted in his 1975 research on monetary policy: "When a measure becomes a target, it ceases to be a good measure." The underlying logic is incentive distortion: once people know a number is being used for evaluation, they adjust their behavior to optimize that number rather than the intent behind it. In software engineering, this explains why metrics like lines of code, defect counts, or even AI token consumption tend to produce gaming behavior once tied to performance. Related to Goodhart's Law are Campbell's Law and the phenomenon of "metric gaming," which together remind us: when choosing metrics, assess how easily they can be manipulated—hard technical metrics (like startup time) are harder to distort than soft behavioral metrics.

Laws That Are "True but Useless"

Linus's Law: Enough Eyeballs Make All Bugs Shallow

"Given enough users of an API, it doesn't matter what you promise in the contract—all observable behavior of the system will be depended on by someone." This law was rated S tier, because the open-source world is full of cases where "accidental behavior becomes the de facto standard": Go's for loop used to not copy the loop variable, tripping up countless people, but the official team took over a dozen versions before daring to change it, because existing code depended on that behavior.

However, another commonly cited "Linus's Law"—"given enough eyeballs, all bugs are shallow"—was relegated to the "pending" zone. The discussants considered it "obviously true but information-free," like how buying more lottery tickets increases your odds of winning—correct but useless. And Linux itself is not bug-free; more people doesn't automatically mean higher quality.

Cunningham's Law and "Annie's Law"

"The best way to get the right answer on the internet is not to ask a question, but to post the wrong answer." This law was jokingly dubbed "Annie's Law" by the discussants—because someone (reportedly a user named Annie) summarized a more precise procedure on Reddit: first ask politely, then post an arrogant and wrong answer from a burner account, and wait for someone to correct you.

The discussants believe that as experts are worn down by the noise on social media, this law's effectiveness is declining—capable responders may have long since unfollowed. But in certain niche communities (like Pokémon card collecting), it still works.

The Law of Software Getting Slower: An S-Tier Diagnosis of the Times

"Software gets slower faster than hardware gets faster." This Wirth's Law received the highest consensus of the session. The discussants shared an experiment: having AI test DOM element insertion and deletion speed on a slow virtual machine yielded microsecond-level results—from a purely technical standpoint, modern browser operations are already extremely fast. Yet the lag users feel is everywhere, because feature bloat, stacked abstractions, and dependency bloat devour the hardware dividend.

One developer summarized half-jokingly: "We've reached the era of running neural networks on GPUs to generate frames because we can't make good graphics anymore." Behind this is real anxiety about industry trends—each generation of software sacrifices responsiveness under the pressure of more features, more complex architectures, and faster delivery.

Conclusion: Laws Are Starting Points for Thinking, Not Answers

Perhaps the most interesting finding of this Tier List is: the programming laws that truly withstand scrutiny tend to describe fundamental constraints on information flow and human cognition (Conway's Law, Goodhart's Law), while those that try to predict specific project management outcomes (Brooks, Hofstadter) appear fragile in the face of environmental change.

AI tools are rewriting many traditional rules of thumb—onboarding speed for newcomers, the cost of understanding code, and even the definition of "who is the author of code" are all changing. But the communication costs revealed by Conway's Law and the incentive distortions revealed by Goodhart's Law—these rules rooted in organizations and human nature—will likely outlast any specific technology.

Next time you hear someone in a conference room cite some "law" to support a decision, you might first ask: What was the original context of this law? Does it still hold today?