Laws of Software Engineering
Laws of Software Engineering
A collection of principles and patterns that shape software systems, teams, and decisions.
56 laws • Click any card to learn more
Level
All Junior Mid-Level Senior
Category
All Architecture Teams Planning Quality Scale Design Decisions
TeamsConway's LawOrganizations design systems that mirror their own communication structure.PlanningPremature Optimization (Knuth's Optimization Principle)Premature optimization is the root of all evil.ArchitectureHyrum's LawWith a sufficient number of API users, all observable behaviors of your system will be depended on by somebody.QualityThe Boy Scout RuleLeave the code better than you found it.DesignYAGNI (You Aren't Gonna Need It)Don't add functionality until it is necessary.TeamsBrooks's LawAdding manpower to a late software project makes it later.ArchitectureGall's LawA complex system that works is invariably found to have evolved from a simple system that worked.ArchitectureThe Law of Leaky AbstractionsAll non-trivial abstractions, to some degree, are leaky.ArchitectureTesler's Law (Conservation of Complexity)Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.CAPArchitectureCAP TheoremA distributed system can guarantee only two of: consistency, availability, and partition tolerance.ArchitectureSecond-System EffectSmall, successful systems tend to be followed by overengineered, bloated replacements.ArchitectureFallacies of Distributed ComputingA set of eight false assumptions that new distributed system designers often make.ArchitectureLaw of Unintended ConsequencesWhenever you change a complex system, expect surprise.+++++ArchitectureZawinski's LawEvery program attempts to expand until it can read mail.150TeamsDunbar's NumberThere is a cognitive limit of about 150 stable relationships one person can maintain.TeamsThe Ringelmann EffectIndividual productivity decreases as group size increases.NTeamsPrice's LawThe square root of the total number of participants does 50% of the work.?⚙⚙TeamsPutt's LawThose who understand technology don't manage it, and those who manage it don't understand it.TeamsPeter PrincipleIn a hierarchy, every employee tends to rise to their level of incompetence.1TeamsBus FactorThe minimum number of team members whose loss would put the project in serious trouble.✓?TeamsDilbert PrincipleCompanies tend to promote incompetent employees to management to limit the damage they can do.PlanningParkinson's LawWork expands to fill the time available for its completion.90%+90%PlanningThe Ninety-Ninety RuleThe first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%.+PlanningHofstadter's LawIt always takes longer than you expect, even when you take into account Hofstadter's Law.PlanningGoodhart's LawWhen a measure becomes a target, it ceases to be a good measure.PlanningGilb's LawAnything you need to quantify can be measured in some way better than not measuring it.QualityMurphy's Law / Sod's LawAnything that can go wrong will go wrong.QualityPostel's LawBe conservative in what you do, be liberal in what you accept from others.QualityBroken Windows TheoryDon't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired.$%QualityTechnical DebtTechnical Debt is everything that slows us down when developing software.QualityLinus's LawGiven enough eyeballs, all bugs are shallow.QualityKernighan's LawDebugging is twice as hard as writing the code in the first place.QualityTesting PyramidA project should have many fast unit tests, fewer integration tests, and only a small number of UI tests.QualityPesticide ParadoxRepeatedly running the same tests becomes less effective over time.QualityLehman's Laws of Software EvolutionSoftware that reflects the real world must evolve, and that evolution has predictable limits.QualitySturgeon's Law90% of everything is crap.ScaleAmdahl's LawThe speedup from parallelization is limited by the fraction of work that cannot be parallelized.ScaleGustafson's LawIt is possible to achieve significant speedup in parallel processing by increasing the problem size.ScaleMetcalfe's LawThe value of a network is proportional to the square of the number of users.1DesignDRY (Don't Repeat Yourself)Every piece of knowledge must have a single, unambiguous, authoritative representation.DesignKISS (Keep It Simple, Stupid)Designs and systems should be as simple as possible.DesignSOLID PrinciplesFive main guidelines that enhance software design, making code more maintainable and scalable.ABCDesignLaw of DemeterAn object should only interact with its immediate friends, not strangers.DesignPrinciple of Least AstonishmentSoftware and interfaces should behave in a way that least surprises users and other developers.DecisionsDunning-Kruger EffectThe less you know about something, the more confident you tend to be.DecisionsHanlon's RazorNever attribute to malice that which is adequately explained by stupidity or carelessness.DecisionsOccam's RazorThe simplest explanation is often the most accurate one.DecisionsSunk Cost FallacySticking with a choice because you've invested time or energy in it, even when walking away helps you.≠MAPREALDecisionsThe Map Is Not the TerritoryOur representations of reality are not the same as reality itself.DecisionsConfirmation BiasA tendency to favor information that supports our existing beliefs or ideas.DecisionsThe Hype Cycle & Amara's LawWe tend to overestimate the effect of a technology in the short run and underestimate the impact in the long run.+DecisionsThe Lindy EffectThe longer something has been in use, the more likely it is to continue being used.?DecisionsFirst Principles ThinkingBreaking a complex problem into its most basic blocks and then building up from there.DecisionsInversionSolving a problem by considering the opposite outcome and working backward from it.80%20%DecisionsPareto Principle (80/20 Rule)80% of the problems result from 20% of the causes.✗DecisionsCunningham's LawThe best way to get the correct answer on the Internet is not to ask a question, it's to post the wrong answer.