Shreyas Study

Appearance

The 56 Laws of Software Engineering ​

Source and attribution: The Laws of Software Engineering were created by Dr. Milan Milanović. Read the original collection at lawsofsoftwareengineering.com.

This Markdown learning article was independently written and compiled by Shreyas Khamkar as a study reference. It is not the original source.

A practical guide for developers, backend engineers, architects, tech leads, and engineering managers ​

Goal: Understand the mental model behind each law, know when it is useful, and connect it to real software-engineering decisions.

This is a practical learning article based on the 56-law structure published by Laws of Software Engineering. The explanations below are intentionally concise and rewritten for learning rather than copied from the source.

How to use this guide ​

Do not try to memorize all 56 laws.

Instead, use them as a mental toolbox:

  • Architecture problem? Think Gall's Law, Leaky Abstractions, CAP, Hyrum's Law.
  • Team problem? Think Conway's Law, Brooks's Law, Bus Factor, Dunbar's Number.
  • Planning problem? Think Hofstadter's Law, Parkinson's Law, Goodhart's Law.
  • Code-quality problem? Think Technical Debt, Boy Scout Rule, Kernighan's Law.
  • Performance problem? Think Amdahl's Law or Gustafson's Law.
  • Design problem? Think KISS, YAGNI, DRY, SOLID, Law of Demeter.
  • Decision problem? Think Occam's Razor, Inversion, First Principles, Sunk Cost.

The real skill is not knowing a quote. It is recognizing which mental model applies to the situation in front of you.

Part I --- Architecture & Complexity ​

1. Gall's Law ​

A complex system that works evolved from a simpler system that worked.

Complex systems are difficult to design correctly in one big step because you cannot predict every interaction in advance.

Practical lesson ​

Start with a small working system:

text
Small working system
        ↓
Observe
        ↓
Improve
        ↓
Extend
        ↓
More capable system

Example ​

Instead of immediately building a huge microservice platform, start with a modular system that solves the real business problem. Extract services when there is evidence that separation is useful.

Remember: Build complexity incrementally.

2. Law of Leaky Abstractions ​

All non-trivial abstractions leak.

An abstraction hides details, but the hidden details eventually affect you.

Examples:

  • ORM → SQL performance still matters.
  • HTTP client → network latency still exists.
  • Docker → operating-system and networking behavior still exists.
  • Cloud storage → network failures and consistency behavior still exist.

Practical lesson ​

Use abstractions, but understand what is underneath them when debugging or optimizing.

Remember: An abstraction reduces complexity; it does not make underlying reality disappear.

3. Tesler's Law --- Conservation of Complexity ​

Every application has some complexity that cannot be eliminated, only moved.

Suppose an accounting system has complicated tax rules.

You can put the complexity:

text
Inside the software

or:

text
On the user

Good design tries to absorb complexity inside the system where possible.

Example ​

A good invoice system automatically calculates tax instead of forcing users to calculate it manually.

Remember: You cannot eliminate all complexity; choose where it lives.

4. CAP Theorem ​

For a distributed data system, when a network partition occurs, you cannot simultaneously guarantee all three of:

  • Consistency
  • Availability
  • Partition tolerance

In practice, network partitions are possible, so distributed systems must make trade-offs between consistency and availability during partitions.

Practical lesson ​

Do not ask:

"Which database is best?"

Ask:

"What consistency and availability behavior does this business actually require?"

5. Hyrum's Law ​

With enough users of an API, every observable behavior will eventually be depended upon by someone.

Your official API contract may say:

text
id
name
status

But consumers may also depend on:

  • response ordering
  • error codes
  • default sorting
  • null behavior
  • date formats
  • status codes
  • timing
  • undocumented quirks

Practical lesson ​

Before changing an API, investigate its real consumers.

Remember: If people can observe it, someone may eventually depend on it.

6. Second-System Effect ​

A small successful system is often followed by a second system that becomes over-engineered.

The team thinks:

"Now we know what we're doing. Let's build the perfect version."

Then the replacement gets:

  • too many abstractions
  • too many features
  • too many configuration options
  • too much architecture

Practical lesson ​

Do not turn lessons from the first system into an excuse to build everything at once.

Connection: YAGNI + KISS.

7. Fallacies of Distributed Computing ​

Distributed systems invalidate many assumptions developers naturally make.

Common false assumptions include:

  1. The network is reliable.
  2. Latency is zero.
  3. Bandwidth is infinite.
  4. The network is secure.
  5. Topology never changes.
  6. There is one administrator.
  7. Transport cost is zero.
  8. The network is homogeneous.

Practical lesson ​

Design for:

text
Timeouts
Retries
Partial failure
Security
Latency
Service discovery
Observability

Remember: A remote call is not the same as a local function call.

8. Law of Unintended Consequences ​

A change can produce effects that were not part of the original intention.

You optimize a database query and accidentally change locking behavior.

You change an API response and break a mobile client.

You add caching and create stale-data bugs.

Practical lesson ​

Before changing a complex system, ask:

text
What am I changing?
Who depends on it?
What side effects are possible?
How will I detect failure?
Can I roll back?

9. Zawinski's Law ​

Every program attempts to expand until it can read mail.

The humorous point is that software tends to accumulate features.

A simple application becomes:

text
Simple app
 ↓
Reports
 ↓
Chat
 ↓
Notifications
 ↓
Calendar
 ↓
Email
 ↓
Everything

Practical lesson ​

Product scope naturally expands unless somebody deliberately controls it.

Connection: YAGNI, Second-System Effect, Parkinson's Law.

Part II --- People, Teams & Organizations ​

10. Conway's Law ​

Organizations design systems that mirror their communication structures.

If three teams communicate poorly, the architecture may end up with three poorly integrated components.

If teams are organized around clear domain boundaries, architecture often follows those boundaries.

Practical lesson ​

Architecture is not only a technical problem.

text
Team structure
      ↓
Communication
      ↓
System boundaries
      ↓
Architecture

11. Brooks's Law ​

Adding manpower to a late software project makes it later.

Why?

New developers require:

  • onboarding
  • explanations
  • code reviews
  • coordination
  • architecture context

And communication paths increase rapidly.

Practical lesson ​

When a project is late, first identify the bottleneck.

Ask:

Can the work actually be parallelized?

12. Little's Law ​

A useful queueing relationship is:

WIP = Throughput × Cycle Time

Where:

  • WIP = work in progress
  • Throughput = completed work per unit of time
  • Cycle time = time to complete work

Example ​

If a team has:

text
20 tasks in progress
5 tasks completed per week

then average cycle time is roughly:

text
20 / 5 = 4 weeks

Practical lesson ​

Too much work in progress can increase waiting and cycle time.

Remember: Start less, finish more.

13. Dunbar's Number ​

Dunbar's Number is the idea that humans have limits on the number of stable social relationships they can maintain.

For software teams, the practical lesson is:

Communication and coordination do not scale indefinitely.

As teams grow, organizations often need:

  • smaller teams
  • clear ownership
  • explicit interfaces
  • fewer unnecessary dependencies

14. Ringelmann Effect & Two-Pizza Rule ​

Ringelmann Effect ​

As groups become larger, individual contribution can decrease because coordination and social loafing increase.

Two-Pizza Rule ​

A popular team heuristic says a team should be small enough to be fed by roughly two pizzas.

The exact number is not sacred.

Practical lesson ​

Prefer small, autonomous teams with clear ownership over giant groups where nobody knows who owns the problem.

15. Price's Law ​

Price's Law suggests that a disproportionate share of output in a group often comes from a relatively small subset of contributors.

Practical lesson ​

Do not assume:

text
10 developers = 10 equal units of output

Productivity varies because of:

  • experience
  • domain knowledge
  • ownership
  • motivation
  • system familiarity
  • task difficulty

Management lesson ​

Build systems that help more people become effective instead of depending permanently on a few heroes.

16. Putt's Law ​

A humorous organizational observation:

Technology decisions are often made by people who are increasingly removed from the technology itself.

As organizations grow, decision-making can drift away from technical reality.

Practical lesson ​

Good technical leadership needs communication between:

text
Business
   ↕
Engineering
   ↕
Architecture

Technical decisions should remain connected to people who understand the consequences.

17. Peter Principle ​

People in organizations tend to be promoted until they reach a level where they are no longer effective.

A great developer is not automatically a great manager.

A great individual contributor may not enjoy people management.

Practical lesson ​

Create multiple career paths:

text
Individual Contributor
        +
Management

Do not make management the only definition of career growth.

18. Bus Factor & Dead Sea Effect ​

Bus Factor ​

How many people could leave before the project becomes seriously endangered?

If:

text
Only one developer understands deployment

your bus factor for deployment is dangerously low.

Dead Sea Effect ​

In some organizations, strong employees leave while less effective employees remain, gradually weakening the team.

Practical lesson ​

Reduce knowledge concentration:

  • documentation
  • pairing
  • code review
  • shared ownership
  • automated deployment

19. Dilbert Principle ​

A satirical principle suggesting organizations sometimes move less effective employees into management because it is easier to contain the damage there.

Practical lesson ​

Treat it as organizational humor, not a scientific law.

The useful lesson is:

Promotion and management selection should be based on actual leadership capability, not simply technical or organizational status.

Part III --- Time, Estimation & Planning ​

20. Hofstadter's Law ​

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Software contains unknowns:

text
Requirements
Dependencies
Bugs
Integration
Testing
Deployment

Practical lesson ​

Estimates are hypotheses, not promises.

Use:

  • smaller tasks
  • historical data
  • milestones
  • buffers
  • frequent reassessment

21. Parkinson's Law ​

Work expands to fill the time available for completion.

Give a task:

text
2 hours → maybe 2 hours
2 weeks → possibly 2 weeks

Practical lesson ​

Use:

  • clear scope
  • acceptance criteria
  • timeboxing
  • small deliverables

Do not use extra time as an excuse for unnecessary features.

22. The Ninety-Ninety Rule ​

A humorous rule:

The first 90% of the code takes 90% of the time; the remaining 10% takes another 90%.

The point is that the final part of software often contains:

  • edge cases
  • integration issues
  • testing
  • deployment
  • production fixes

Practical lesson ​

Do not declare a feature "almost done" before considering the last-mile work.

23. Goodhart's Law & the Cobra Effect ​

Goodhart's Law ​

When a measure becomes a target, it stops being a good measure.

If you measure developers by:

text
Lines of code

they may produce more code.

If you measure:

text
Number of tickets closed

they may optimize for ticket count rather than business value.

Cobra Effect ​

A poorly designed incentive can produce behavior that makes the original problem worse.

Practical lesson ​

Choose metrics carefully.

Measure outcomes, not easily gamed proxies.

24. Gilb's Law ​

A practical formulation is:

Anything you can measure can be improved.

If you do not know:

text
Deployment frequency
Lead time
Error rate
Latency
Failure rate
Customer impact

you are mostly guessing.

Practical lesson ​

Turn vague problems into measurable ones.

Instead of:

"The API is slow."

Measure:

text
p50
p95
p99
database time
external API time
CPU
memory

25. Knuth's Optimization Principle ​

Premature optimization is the root of much unnecessary complexity.

The practical version:

Measure first. Optimize the actual bottleneck.

Bad:

text
"I think this query might be slow."
→ rewrite everything

Better:

text
Measure
 ↓
Find bottleneck
 ↓
Optimize
 ↓
Measure again

Part IV --- Quality, Maintenance & Evolution ​

26. Murphy's Law / Sod's Law ​

If something can go wrong, eventually it probably will.

Production examples:

  • database unavailable
  • network timeout
  • duplicate message
  • invalid input
  • partial deployment
  • external API failure

Practical lesson ​

Design for failure:

text
Timeouts
Retries
Validation
Idempotency
Monitoring
Graceful degradation
Recovery

27. Postel's Law ​

Traditionally:

Be conservative in what you send, liberal in what you accept.

For example, an API may accept harmless variations in input while producing strictly valid output.

Important modern caution ​

Blind tolerance can hide bugs and create security problems.

Practical lesson ​

Be predictable in what you produce, and tolerant only where that tolerance is safe and intentional.

28. Broken Windows Theory ​

A neglected problem signals that poor quality is acceptable.

One bad piece of code becomes:

text
One shortcut
 ↓
Another shortcut
 ↓
More messy code
 ↓
Nobody wants to clean it
 ↓
Technical debt grows

Practical lesson ​

Fix small quality problems before they become the accepted norm.

29. The Boy Scout Rule ​

Leave the code better than you found it.

You do not need to rewrite the whole system.

If you touch:

text
A messy method

make a small improvement:

text
Rename variable
Extract method
Remove dead code
Add test
Improve error handling

Practical lesson ​

Small improvements compound.

30. Technical Debt ​

Technical debt is the future cost created by shortcuts, poor design, outdated dependencies, missing tests, or accumulated complexity.

Not all debt is bad.

A conscious shortcut can be rational if:

text
Business value now
+
Known cost later
+
Repayment plan

Dangerous debt ​

Debt becomes dangerous when:

text
Ignored
 ↓
Compounds
 ↓
Slows every change
 ↓
Team becomes afraid to modify code

31. Linus's Law ​

Given enough eyeballs, all bugs are shallow.

The idea is that wider review and collaboration can expose bugs that one developer misses.

Practical lesson ​

Use:

  • code review
  • open source collaboration
  • pair programming
  • testing
  • observability

But remember: simply having many people is not enough. They must actually inspect and reason about the code.

32. Kernighan's Law ​

Debugging is twice as hard as writing the code in the first place.

If you write code at the limit of your cleverness, you may not be able to understand it later.

Practical lesson ​

Prefer:

text
Readable
Predictable
Boring
Testable

over:

text
Clever
Dense
Magical
Hard to explain

33. Testing Pyramid & Beyoncé Rule ​

Testing Pyramid ​

Prefer many:

text
Unit tests

fewer:

text
Integration tests

and relatively few:

text
UI/end-to-end tests

because lower-level tests are generally faster and easier to diagnose.

Beyoncé Rule ​

If you liked it, you should have put a test on it.

The humorous lesson is:

Important behavior should be protected by automated tests.

34. The Pesticide Paradox ​

A pesticide eventually becomes less effective when pests adapt.

Testing has a similar problem:

Running the same tests repeatedly does not guarantee finding new classes of bugs.

Practical lesson ​

Continuously evolve your tests:

text
New requirements
New edge cases
New failure modes
New test strategies

Do not rely only on the same happy-path tests forever.

35. Lehman's Laws ​

Software in the real world must evolve.

As systems evolve:

  • complexity tends to increase
  • maintenance becomes harder
  • changes can slow future changes
  • teams need continuous adaptation and restructuring

Practical lesson ​

A successful software system is not "finished."

It requires:

text
Feature development
+
Refactoring
+
Testing
+
Architecture evolution
+
Operational improvement

36. Sturgeon's Law ​

"90% of everything is crud."

The exact percentage is deliberately provocative, not a measured software statistic.

The useful lesson:

Not every feature, idea, library, pattern, or code path is equally valuable.

Practical lesson ​

Focus on high-value work.

Do not treat every request as equally important.

Part V --- Scale, Performance & Growth ​

37. Amdahl's Law ​

A system's maximum speedup is limited by the portion that cannot be parallelized.

If:

text
90% of work can be parallelized
10% is sequential

then infinite parallelism cannot make the system infinitely fast.

The sequential 10% becomes the bottleneck.

Practical lesson ​

Find the serial bottleneck before adding more workers.

This applies to:

  • CPUs
  • databases
  • distributed processing
  • organizational approvals
  • deployment pipelines

38. Gustafson's Law ​

Gustafson's Law provides a more optimistic view of parallel computing.

Instead of asking:

"How much faster can we run the same fixed problem?"

it asks:

"How much larger a problem can we solve with more resources in roughly the same time?"

Practical lesson ​

More resources can enable larger workloads, not just faster execution.

This is why scale-out systems can be valuable even when speedup of one fixed task is limited.

39. Metcalfe's Law, Sarnoff's Law & Reed's Law ​

These are network-effect models.

Metcalfe's Law ​

A network's potential value grows roughly with the square of the number of connected users.

Sarnoff's Law ​

For broadcast networks, value is more closely related to the number of viewers.

Reed's Law ​

For group-forming networks, value can potentially grow extremely rapidly because users can create many subgroups.

Practical lesson ​

Different systems benefit from different network effects.

Do not assume every network product scales its value in exactly the same way.

Part VI --- Coding & Design Principles ​

40. DRY --- Don't Repeat Yourself ​

Every piece of knowledge should have a single authoritative representation.

Important distinction:

DRY is about duplicated knowledge, not simply identical text.

Bad:

text
Tax rule copied into:
Sales
Purchase
Invoice
Report

If the tax rule changes, multiple places must change.

Practical lesson ​

Centralize knowledge that must remain consistent.

But do not create abstractions merely because two lines happen to look similar.

Connection: Rule of Three + YAGNI.

41. KISS --- Keep It Simple ​

Prefer the simplest solution that correctly solves the problem.

Simple code is usually:

  • easier to understand
  • easier to test
  • easier to debug
  • easier to modify

Example ​

Do not create:

text
Factory
FactoryFactory
StrategyFactoryProvider

when:

text
A simple method

solves the actual problem.

Remember ​

Simple does not mean simplistic.

42. YAGNI --- You Aren't Gonna Need It ​

Do not build functionality until it is actually necessary.

Developer thinking:

"We might need this in the future."

Then six months later:

text
Feature unused
+
Complexity maintained
+
Tests maintained
+
Bugs possible

Practical lesson ​

Build what you need now while keeping the design changeable enough for future requirements.

43. SOLID Principles ​

SOLID is a group of five object-oriented design principles.

S --- Single Responsibility ​

A class should have one cohesive reason to change.

O --- Open/Closed ​

Software should be extensible without repeatedly modifying stable code.

L --- Liskov Substitution ​

Subtypes should be usable wherever their base type is expected without breaking behavior.

I --- Interface Segregation ​

Do not force clients to depend on methods they do not need.

D --- Dependency Inversion ​

High-level code should depend on abstractions rather than concrete implementation details.

Practical warning ​

SOLID is not a command to create interfaces and classes everywhere.

Over-applying SOLID can create unnecessary abstraction.

Use it where it reduces real coupling and complexity.

44. Law of Demeter ​

Only talk to your immediate friends.

Avoid:

csharp
order.GetCustomer()
     .GetAddress()
     .GetCity()
     .GetZipCode();

This exposes internal structure.

Prefer:

csharp
order.GetShippingZipCode();

Practical lesson ​

Each object should know as little as reasonably possible about the internal structure of other objects.

Remember: Don't talk to strangers.

45. Principle of Least Astonishment ​

Software should behave the way users and developers naturally expect.

If a button looks like:

text
Save

people expect it to save.

If:

text
Delete

actually archives the record, the interface surprises users.

The same applies to APIs:

text
GetCustomer()

should not unexpectedly modify the customer.

Practical lesson ​

Follow established conventions unless you have a strong reason not to.

Part VII --- Decision-Making & Cognitive Biases ​

46. Dunning-Kruger Effect & Impostor Syndrome ​

Dunning-Kruger Effect ​

People with limited knowledge can sometimes overestimate their understanding because they lack enough knowledge to recognize what they are missing.

Impostor Syndrome ​

Capable people may underestimate their own competence and feel they do not deserve their position.

These can coexist:

text
Low knowledge → overconfidence
High knowledge → self-doubt

Neither should be treated as a diagnosis or universal rule.

Practical lesson ​

Use:

text
Evidence
Feedback
Testing
Mentorship
Continuous learning

instead of confidence alone.

47. Hanlon's Razor ​

Do not attribute to malice what can reasonably be explained by error or carelessness.

A developer deploys a broken configuration.

Possible explanation:

text
Mistake

before:

text
Intentional sabotage

Practical lesson ​

When debugging people problems, start with:

text
Misunderstanding
Missing context
Bad process
Human error

before assuming bad intentions.

This does not mean ignoring genuine misconduct when evidence exists.

48. Occam's Razor ​

Prefer the simplest explanation that adequately fits the evidence.

API is returning 404?

Check:

text
Wrong URL?
Wrong route?
Wrong HTTP method?

before:

text
Kubernetes networking failure
DNS failure
Distributed-system conspiracy

Important distinction ​

Occam's Razor does not say:

"The simplest explanation is always true."

It says:

Don't add complexity without evidence.

49. Sunk Cost Fallacy ​

Past investment is already spent.

Bad reasoning:

"We spent two years building this, so we must continue."

Better question:

"If we had not already invested anything, would we choose this project today?"

Practical lesson ​

Use future value and current evidence to decide whether to:

text
Continue
Pivot
Reduce scope
Stop

50. The Map Is Not the Territory ​

A model of reality is not reality itself.

Examples:

text
Architecture diagram ≠ production system
API documentation ≠ actual behavior
Database schema ≠ actual data quality
Requirement document ≠ user needs
Metrics dashboard ≠ complete reality

Practical lesson ​

Validate models against the real world.

text
Model
 ↓
Test against reality
 ↓
Update model

51. Confirmation Bias ​

People naturally look for evidence supporting what they already believe.

Developer:

"The database is slow."

Then every symptom gets interpreted as evidence of a database problem.

Better approach ​

Actively search for evidence that could prove your hypothesis wrong.

Ask:

text
What would I expect if my theory were false?
Can I measure it?
What competing explanation exists?

52. Hype Cycle & Amara's Law ​

Hype Cycle ​

New technology often goes through:

text
Excitement
 ↓
Inflated expectations
 ↓
Disappointment
 ↓
Practical understanding
 ↓
Useful adoption

Amara's Law ​

We tend to overestimate technology's short-term impact and underestimate its long-term impact.

Practical lesson ​

Avoid both extremes:

text
"AI will solve everything tomorrow."

and:

text
"AI is useless."

Evaluate technology based on evidence, cost, risk, and actual business value.

53. Lindy Effect ​

The Lindy Effect suggests that for some non-perishable things, the longer a technology or idea has survived, the longer it may plausibly continue to be useful.

Examples of durable ideas include:

  • Unix concepts
  • relational databases
  • TCP/IP
  • structured testing
  • version control
  • simple modular design

Practical lesson ​

Do not chase novelty merely because it is new.

New technology can be valuable, but proven technology often has enormous accumulated knowledge and ecosystem value.

54. First Principles Thinking ​

Instead of copying how something is usually done, break the problem down into fundamental facts.

Example:

Instead of:

"Everyone uses microservices, so we need microservices."

Ask:

text
What problem are we solving?
How many teams?
How independent are deployments?
What scale?
What failure isolation is required?
What operational cost can we support?

Then design from those constraints.

Practical lesson ​

Start with reality, not fashion.

55. Inversion ​

Instead of asking:

"How do I make this system successful?"

ask:

"What would definitely make this system fail?"

For example:

text
How do I build a reliable API?

Invert it:

text
What would make the API unreliable?

Answers:

text
No timeouts
No monitoring
No tests
No validation
Unbounded retries
Single point of failure
Unknown dependencies

Now eliminate those failure modes.

Practical lesson ​

Sometimes the fastest route to a good solution is identifying what must not happen.

56. Pareto Principle --- 80/20 Rule ​

A common observation:

A large share of results often comes from a relatively small share of causes.

In software, examples might look like:

text
20% of endpoints → 80% of traffic
20% of bugs → 80% of incidents
20% of features → 80% of usage
20% of queries → 80% of database load

The exact ratio is not guaranteed.

Practical lesson ​

Find the high-impact areas before trying to optimize everything.

57. Cunningham's Law ​

The best way to get the right answer on the Internet is to post the wrong answer.

The idea is humorous: people are often highly motivated to correct an incorrect statement.

Practical lesson ​

When asking technical questions:

text
Context
+
What you tried
+
Your current hypothesis
+
Evidence

gets much better responses than:

text
"Why doesn't this work?"

Important caveat ​

Do not intentionally spread misinformation in situations where incorrect information could cause harm.

A Practical Mental Model: How the Laws Work Together ​

The laws become much more useful when combined.

When designing a new system ​

Use:

text
Gall's Law
     ↓
Start small

YAGNI
     ↓
Build only what is needed

KISS
     ↓
Keep the design understandable

SOLID
     ↓
Separate real responsibilities

DIP
     ↓
Protect business logic from infrastructure

OCP
     ↓
Make genuine variation extensible

When debugging ​

Use:

text
Occam's Razor
     ↓
Start with simple explanations

Hanlon's Razor
     ↓
Don't assume bad intentions

Murphy's Law
     ↓
Expect failure to be possible

Law of Leaky Abstractions
     ↓
Look underneath the abstraction

Kernighan's Law
     ↓
Keep the code understandable

Confirmation Bias
     ↓
Try to disprove your hypothesis

When changing an API ​

Use:

text
Hyrum's Law
     ↓
Someone may depend on observable behavior

Least Astonishment
     ↓
Keep behavior predictable

Postel's Law
     ↓
Be intentional about tolerance

Leaky Abstractions
     ↓
Understand underlying behavior

Law of Demeter
     ↓
Avoid exposing unnecessary structure

When a project is late ​

Use:

text
Hofstadter's Law
     ↓
Expect uncertainty

Parkinson's Law
     ↓
Control scope and time

Brooks's Law
     ↓
Don't blindly add people

Little's Law
     ↓
Reduce excessive WIP

Pareto
     ↓
Find the highest-impact work

When performance is bad ​

Do not immediately optimize everything.

Use:

text
Measure
  ↓
Knuth's Optimization Principle
  ↓
Find bottleneck
  ↓
Amdahl's Law
  ↓
Find sequential/serial bottleneck
  ↓
Optimize
  ↓
Measure again

When a codebase is becoming messy ​

Use:

text
Boy Scout Rule
     ↓
Make small improvements

Broken Windows
     ↓
Don't normalize poor quality

Technical Debt
     ↓
Identify accumulated cost

DRY
     ↓
Remove duplicated knowledge

Rule of Three
     ↓
Wait for real patterns before abstraction

KISS
     ↓
Avoid unnecessary complexity

The Most Important 15 to Learn First ​

If you are learning software engineering and cannot study all 56 at once, start here:

# Principle Main lesson

1 YAGNI Don't build unnecessary features 2 KISS Prefer simple solutions 3 DRY Don't duplicate knowledge 4 SOLID Design maintainable OO code 5 Hyrum's Law Observable behavior becomes a contract 6 Gall's Law Grow systems incrementally 7 Law of Leaky Abstractions Understand what abstractions hide 8 Brooks's Law More people don't automatically mean more speed 9 Parkinson's Law Work expands to fill available time 10 Murphy's Law Design for failure 11 Technical Debt Shortcuts create future cost 12 Occam's Razor Start with simple evidence-based explanations 13 Law of Demeter Reduce unnecessary coupling 14 First Principles Reason from fundamentals 15 Pareto Focus on high-impact work

A Developer's Daily Checklist ​

Before writing code:

text
[ ] What problem am I actually solving?
[ ] Do I really need this feature?
[ ] What is the simplest solution?
[ ] Am I designing for a real requirement or an imagined future?

Before creating an abstraction:

text
[ ] Is there a real pattern?
[ ] Is this repeated enough to justify abstraction?
[ ] Am I following YAGNI?
[ ] Am I creating complexity too early?

Before changing existing code:

text
[ ] Who depends on this?
[ ] What behavior is observable?
[ ] Could Hyrum's Law apply?
[ ] Why does this code exist?
[ ] Could there be unintended consequences?

Before optimizing:

text
[ ] Did I measure the problem?
[ ] Where is the actual bottleneck?
[ ] Am I optimizing because of evidence or intuition?
[ ] What will the optimization cost in complexity?

Before debugging:

text
[ ] What is the simplest plausible explanation?
[ ] What evidence supports it?
[ ] What evidence would disprove it?
[ ] Could the abstraction be leaking?
[ ] Could a recent change have caused a side effect?

Before deploying:

text
[ ] What can fail?
[ ] What happens if the network fails?
[ ] What happens if the database fails?
[ ] What happens if the request is duplicated?
[ ] How will we detect the failure?
[ ] Can we recover or roll back?

Before starting a large project:

text
[ ] Can we start with a smaller working system?
[ ] What is the minimum valuable scope?
[ ] What can be parallelized?
[ ] Where are the dependencies?
[ ] What is the likely bottleneck?
[ ] How will we measure success?

The Big Picture ​

These 56 laws can be reduced to a few powerful habits.

1. Keep complexity under control ​

text
KISS
YAGNI
DRY
Gall's Law
Tesler's Law
Leaky Abstractions

2. Respect reality ​

text
Hyrum's Law
Murphy's Law
CAP
Distributed Computing Fallacies
Unintended Consequences
Map ≠ Territory

3. Design for change ​

text
SOLID
Law of Demeter
Technical Debt
Lehman's Laws
Boy Scout Rule
Broken Windows

4. Think about people ​

text
Conway
Brooks
Little
Dunbar
Ringelmann
Peter
Bus Factor

5. Make better decisions ​

text
Occam
Hanlon
First Principles
Inversion
Confirmation Bias
Sunk Cost
Pareto

Final Mental Model ​

A senior engineer does not simply know more technologies.

A senior engineer gets better at recognizing patterns of failure.

When you see:

text
A huge new architecture

think:

Second-System Effect + YAGNI + Gall's Law

When you see:

text
A 2000-line class

think:

SRP + KISS + Technical Debt

When you see:

text
A breaking API change

think:

Hyrum's Law

When you see:

text
A late project

think:

Brooks + Parkinson + Little's Law

When you see:

text
A production outage

think:

Murphy + Occam + Leaky Abstractions

When you see:

text
A performance problem

think:

Measure + Knuth + Amdahl

When you see:

text
A difficult decision

think:

First Principles + Inversion + Pareto + Sunk Cost

And when you see a complicated solution, ask the most important question:

"What is the simplest solution that solves the actual problem?"

That single question connects a surprisingly large portion of software-engineering wisdom.

Quick Reference --- All 56 ​

                        \# Law / Principle       Core idea

                         1 Gall's Law            Complex systems evolve
                                                 from simpler working
                                                 systems

                         2 Law of Leaky          Abstractions eventually
                           Abstractions          expose underlying
                                                 complexity

                         3 Tesler's Law          Complexity cannot be
                                                 eliminated, only moved

                         4 CAP Theorem           Distributed systems face
                                                 consistency/availability
                                                 trade-offs during
                                                 partitions

                         5 Hyrum's Law           Observable behavior
                                                 becomes an implicit
                                                 contract

                         6 Second-System Effect  Success can encourage
                                                 overengineering of the
                                                 replacement

                         7 Distributed Computing Networks are not free,
                           Fallacies             reliable, instant, or
                                                 magically secure

                         8 Unintended            Changes can create
                           Consequences          unexpected side effects

                         9 Zawinski's Law        Software tends to expand
                                                 in scope

                        10 Conway's Law          Architecture reflects
                                                 communication structures

                        11 Brooks's Law          Adding people to a late
                                                 project can make it later

                        12 Little's Law          WIP, throughput, and cycle
                                                 time are mathematically
                                                 related

                        13 Dunbar's Number       Human coordination has
                                                 practical limits

                        14 Ringelmann /          Large teams create
                           Two-Pizza             coordination overhead

                        15 Price's Law           Output is often
                                                 concentrated among a
                                                 smaller group

                        16 Putt's Law            Technical decisions can
                                                 drift away from technical
                                                 expertise

                        17 Peter Principle       People can be promoted
                                                 beyond their effective
                                                 level

                        18 Bus Factor / Dead Sea Knowledge concentration
                           Effect                and talent loss create
                                                 organizational risk

                        19 Dilbert Principle     Organizational promotions
                                                 can produce perverse
                                                 outcomes

                        20 Hofstadter's Law      Complex work often takes
                                                 longer than expected

                        21 Parkinson's Law       Work expands to fill
                                                 available time

                        22 Ninety-Ninety Rule    The last part of software
                                                 often takes
                                                 disproportionately long

                        23 Goodhart / Cobra      Targets and incentives can
                           Effect                distort behavior

                        24 Gilb's Law            Measurement enables
                                                 improvement

                        25 Knuth's Optimization  Measure before optimizing
                           Principle             

                        26 Murphy / Sod's Law    Design assuming things can
                                                 fail

                        27 Postel's Law          Be intentional about
                                                 strict output and tolerant
                                                 input

                        28 Broken Windows        Small quality problems can
                                                 normalize larger ones

                        29 Boy Scout Rule        Leave code better than you
                                                 found it

                        30 Technical Debt        Shortcuts create future
                                                 cost and interest

                        31 Linus's Law           Broad review can expose
                                                 more bugs

                        32 Kernighan's Law       Clever code is expensive
                                                 to debug

                        33 Testing Pyramid /     Many fast tests; protect
                           Beyoncé Rule          important behavior with
                                                 tests

                        34 Pesticide Paradox     Repeating the same tests
                                                 misses new bug classes

                        35 Lehman's Laws         Software must continuously
                                                 evolve

                        36 Sturgeon's Law        Not all ideas or outputs
                                                 are equally valuable

                        37 Amdahl's Law          Serial work limits speedup

                        38 Gustafson's Law       More resources can enable
                                                 larger workloads

                        39 Metcalfe / Sarnoff /  Different network
                           Reed                  structures create
                                                 different growth effects

                        40 DRY                   Keep duplicated knowledge
                                                 authoritative in one place

                        41 KISS                  Prefer simple solutions

                        42 YAGNI                 Don't build what you don't
                                                 currently need

                        43 SOLID                 Principles for
                                                 maintainable
                                                 object-oriented design

                        44 Law of Demeter        Talk to immediate
                                                 collaborators, not deep
                                                 object graphs

                        45 Least Astonishment    Software should behave as
                                                 people reasonably expect

                        46 Dunning-Kruger /      Confidence and competence
                           Impostor Syndrome     can be misaligned

                        47 Hanlon's Razor        Prefer error over assumed
                                                 malice when evidence
                                                 allows

                        48 Occam's Razor         Prefer the simplest
                                                 explanation consistent
                                                 with evidence

                        49 Sunk Cost Fallacy     Past investment should not
                                                 dictate future decisions

                        50 Map Is Not Territory  Models are not reality

                        51 Confirmation Bias     People seek evidence
                                                 supporting existing
                                                 beliefs

                        52 Hype Cycle / Amara's  Technology expectations
                           Law                   are often miscalibrated
                                                 over time

                        53 Lindy Effect          Durable ideas may have
                                                 greater expected longevity

                        54 First Principles      Reason from fundamental
                                                 facts

                        55 Inversion             Solve problems by
                                                 identifying and preventing
                                                 failure

                        56 Pareto / Cunningham's Focus on high-impact
                           Law                   causes; challenge
                                                 assumptions and seek
                                                 correction

Closing ​

The purpose of these laws is not to turn software engineering into a collection of slogans.

They are thinking tools.

A strong engineer learns to move from:

text
"What code should I write?"

to:

text
"What problem am I solving?"
        ↓
"What assumptions am I making?"
        ↓
"What can fail?"
        ↓
"Who depends on this?"
        ↓
"What is the simplest solution?"
        ↓
"How will I know it works?"
        ↓
"What happens when the system evolves?"

That shift---from writing code to reasoning about systems---is one of the biggest steps from junior engineering toward senior engineering.

Source ​

This guide follows the 56-law structure published by Laws of Software Engineering and is intended as a learning companion, not a replacement for the original material.

Official reference: https://lawsofsoftwareengineering.com/

The site's book page organizes the material into seven parts: Architecture & Complexity; People, Teams & Organizations; Time, Estimation & Planning; Quality, Maintenance & Evolution; Scale, Performance & Growth; Coding & Design Principles; and Decision-Making & Biases.

Built from Markdown with VitePress.