By Software engineers treat certain “laws” as gospel truth. Conway’s Law. Brooks’s Law. DRY. They’re cited in code reviews, architecture discussions, and planning meetings like religious texts. However, here’s the uncomfortable truth: some of these laws are outdated cargo-cult thinking, and others only apply in specific contexts that don’t match most teams’ reality. Moreover, “Laws of Software Engineering” hit #1 on Hacker News today (854 points, 430 comments), sparking intense debate about which principles are timeless truths versus outdated dogma.
The 430-comment thread exposed deep divisions between systems programmers, full-stack developers, and AI-assisted coders about what laws still matter in 2026. As a result, engineers waste time following outdated principles. Consequently, teams over-engineer because “the law says so.” Understanding which laws still apply—and which don’t—makes better engineers and better software. Therefore, we’re going to rank the 7 laws that matter in 2026 and call out 3 popular laws that are overrated or misapplied. This is not a listicle. This is an argument.
The 7 Software Engineering Laws That Survive 2026
Some software engineering principles have survived decades because they describe fundamental constraints about organizational dynamics, human behavior, and system complexity. Furthermore, these seven span architecture, design, and pragmatism—and remain relevant regardless of whether you’re building microservices at FAANG or a monolith at a startup.
Conway’s Law (“Organizations design systems that mirror their communication structure”) is still brutally relevant. As companies grow from 10 to 100 engineers organized into teams, suddenly the monolith is “unscalable” and they need microservices. However, breaking a monolith without aligning services to teams creates the worst of both worlds: operational complexity of microservices plus coordination overhead of cross-team dependencies. In fact, Amazon’s two-pizza teams directly produced small, autonomous services—strategic application of Conway’s Law.
Gall’s Law (“Complex working systems evolved from simple working systems”) remains true: you can’t design complexity upfront successfully. Moreover, AI hasn’t changed this. Start simple, evolve. The anti-pattern? Second-system effect and over-engineering from day one.
Hyrum’s Law (“With sufficient API users, all observable behaviors become dependencies”) is MORE true in the AI era. In fact, AI generates code that depends on undocumented behaviors. For example, Google Maps API users relied on undocumented geocoding shortcuts. When Google enforced stricter policies, those “features” disappeared, breaking third-party apps. Therefore, any observable behavior becomes your API contract, whether you document it or not.
The Law of Leaky Abstractions (“All non-trivial abstractions leak underlying complexity”) persists everywhere. ORMs generate bad SQL. Serverless has cold starts. React state management complexity. In 2026, abstractions multiply, but they all still leak.
Postel’s Law (“Be conservative in what you send, liberal in what you accept”) remains foundational for API design, data validation, and backward compatibility. The caveat: security contexts require strict validation. However, for input parsing, protocol design, and API versioning, this principle endures.
Principle of Least Astonishment (“Software behaves in ways least surprising to users”) is a UX and API design foundation. Moreover, AI-generated interfaces need extra attention here—unexpected behavior breaks user trust immediately.
YAGNI (“You Aren’t Gonna Need It”) fights over-engineering and becomes MORE critical with AI. In fact, AI makes it too easy to generate unnecessary features. Therefore, don’t implement functionality until actually needed, not when you merely foresee needing it. This principle directly combats the temptation to build “just in case.”
The 3 Laws That Are Overrated or Misapplied
Time to challenge sacred cows. Furthermore, three popular laws are either misquoted, context-dependent, or taken too far—leading to bad engineering decisions.
“Premature Optimization is the Root of All Evil” is misquoted and cargo-culted. Engineers cite this to justify inefficient code, but the FULL quote from Donald Knuth adds critical context: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”
The cargo cult problem: engineers extend this maxim to “you should never optimize your code.” However, what Knuth actually meant: focus on algorithm design before micro-optimizations. Specifically, don’t waste time micro-optimizing non-critical paths. DO optimize the critical 3%. Moreover, the context has also changed—cloud and serverless economics (cold starts, per-request billing) altered optimization timing. In addition, AI code generators make optimization faster and cheaper. Know the difference between premature and necessary optimization.
Brooks’s Law (“Adding manpower to a late software project makes it later”) is based on 1975 assumptions. The original context: waterfall methodology, manual integration, and massive communication overhead.
The 2026 reality looks different. Furthermore, teams have async communication (Slack, Notion), CI/CD pipelines catching issues automatically, AI-assisted code review reducing bottlenecks, Infrastructure as Code making setup reproducible, and activity tracking providing visibility without meetings. Consequently, these tools don’t eliminate Brooks’s Law, but they shift the curve. In fact, the team size at which overhead becomes problematic is larger now than in 1975. Brooks’s Law isn’t WRONG—modern DevOps practices changed when and how it applies. As a result, adding 2 senior engineers with good onboarding to a late project in 2026 differs significantly from adding 10 junior engineers in 1975.
DRY (Don’t Repeat Yourself) is taken too far. The principle is often misinterpreted as “don’t duplicate code,” but it’s actually about meaning, knowledge, and intent. In reality, DRY is about ensuring that every piece of knowledge has a single, authoritative source of truth.
The over-abstraction trap: bad abstractions come from fear of duplication. Furthermore, two pieces of code can look similar but represent different knowledge. If they evolve differently later, your shared abstraction becomes a liability. Moreover, overusing abstraction in the name of reusability leads to complex, hard-to-follow code with multiple layers developers must navigate to understand underlying logic.
The microservices problem is even worse. In fact, a “commons” shared library often becomes one of the worst nightmares of microservice architecture, creating a dependency structure that leads to a distributed monolith where all the benefits of microservice architecture die. The better principle: duplication is better than the wrong abstraction. Duplicated code that’s easy to understand beats an abstraction that’s hard to modify. Only abstract once you fully understand the domain. Therefore, microservices deliberately duplicate models for autonomy. When different contexts might evolve separately, duplication protects boundaries.
The AI Coding Era Impact
AI is rewriting assumptions about coding speed, optimization timing, and abstraction. In 2026, 52% of developers use AI coding tools, yet 96% don’t fully trust AI-generated code. Consequently, the need for software engineering principles is MORE important, not less.
Which laws become MORE important with AI? First, Hyrum’s Law—AI generates code depending on undocumented behaviors. Second, Gall’s Law—don’t let AI generate complex upfront designs; start simple. Third, YAGNI—AI makes it too easy to generate unnecessary features. Finally, Principle of Least Astonishment—AI-generated interfaces need extra UX scrutiny.
Which laws become LESS relevant? First, Premature Optimization—AI makes optimization faster and cheaper, changing the cost-benefit calculation. Second, DRY—AI can manage duplication better; schema-to-code generation is the “ultimate DRY solution.”
The new reality: AI-generated code looks good but often violates every principle. Moreover, the skill shifted from initial writing to code review and refactoring. Therefore, engineers must apply principles AFTER generation, not during. For DRY, prompt with “extract duplicated logic into reusable function.” Engineers must adapt their application of laws to AI-assisted workflows. The fundamentals still apply, but the context changed.
The Law Nobody Talks About: Context
Here’s the real insight that the 430-comment Hacker News debate proves: every engineering principle depends on context. Specifically, team size (solo developer vs. 100-person org), scale (100 users vs. 100 million), domain (enterprise B2B vs. consumer app), technology stack (monolith vs. microservices, cloud vs. on-prem), and constraints (time, budget, regulatory requirements).
The real skill isn’t memorizing 56 laws from lawsofsoftwareengineering.com. It’s knowing WHEN to apply which principle. Engineers argue in the comments because they’re working in different contexts. For example, systems programmers from the 1970s-1990s learned these laws in school and have strong opinions about “proper” engineering. Meanwhile, modern full-stack developers in cloud-native, microservices environments see different constraints and tooling. In addition, AI-assisted coders from 2025-2026 are rewriting assumptions about everything.
The cargo cult warning: teams enforce DRY without understanding when duplication is better. Engineers avoid optimization because “Knuth said so” while ignoring the “critical 3%” caveat. Brooks’s Law gets cited to avoid adding needed resources. Architecture decisions are justified with “Conway’s Law” without examining actual team structure. The solution: think critically, understand context, question assumptions. The laws are tools, not commandments.
The Real Engineering Skill
We’ve ranked 7 laws that matter (Conway’s, Gall’s, Hyrum’s, Leaky Abstractions, Postel’s, Least Astonishment, YAGNI) and called out 3 that are overrated or misapplied (Premature Optimization quote, Brooks’s Law in modern DevOps, DRY taken too far). However, the meta-insight is context.
Don’t cargo-cult principles. Understand the context in which they were created, the problems they solve, and when they don’t apply. Moreover, AI is changing the game. In addition, modern tooling shifted the curves. Your context matters—and it’s different from the 1975 context when many of these laws were written.
What’s your most overrated software engineering law? Which principle do you see cargo-culted the most? The best engineers don’t follow all the laws. They know which laws apply in their context and which to ignore. That’s the real skill.
