Empirical laws of software development

Importance Domain Name Content Source
3 AI Asimov's Three Laws of Robotics 1) A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2) A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
3) A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.
link
4 Coding Knuth's optimization principle Premature optimization is the root of all evil. link
4 Coding When debugging, novices insert corrective code, experts remove defective code link
3 Coding Eagleson's Law of Programming Any code of your own that you haven't looked at for six or more months, might as well have been written by someone else. link
3 Coding Flon’s Axiom There does not now, nor will there ever, exist a programming language in which it is least bit hard to write bad programs. link
3 Communication Wiio's laws 1) Communication usually fails, except by accident.
1.1) If communication can fail, it will.
1.2) If communication cannot fail, it still most usually fails.
1.3) If communication seems to succeed in the intended way, there's a misunderstanding.
1.4) If you are content with your message, communication certainly fails.
2) If a message can be interpreted in several ways, it will be interpreted in a manner that maximizes the damage.
3) There is always someone who knows better than you what you meant with your message.
4) The more we communicate, the worse communication succeeds.
4.1) The more we communicate, the faster misunderstandings propagate.
5) In mass communication, the important thing is not how things are but how they seem to be.
6) The importance of a news item is inversely proportional to the square of the distance.
7) The more important the situation is, the more probably you forget an essential thing that you remembered a moment ago.
link
5 Communication Courtois's Rule If people listened to themselves more often, they'd talk less. link
5 Communication Miller's law To understand what another person is saying, you must assume that it is true and try to imagine what it could be true of. link
4 Communication Sayre's law In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake. link
3 Communication Hanlon's Razor Never attribute to malice that which can be adequately explained by stupidity. link
2 Communication Godwin’s Law As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1 link
4 Company Dilbert principle In a hierarchy every employee tends to rise to his level of incompetence. link
4 Company Peter principle people in a hierarchy tend to rise to their level of incompetence link
3 Company Conway's law organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations link
3 Company Gibrat's law the proportional rate of growth of a firm is independent of its absolute size link
3 Company O'Sullivan's first law All organizations that are not actually right-wingwill over time become left-wing. link
1 Company Joy’s Law no matter who you are, most of the smartest people work for someone else link
5 Estimation / time management Frisch's Law You cannot have a baby in one month by getting nine women pregnant. link
5 Estimation / time management Hofstadter's law It always takes longer than you expect, even when you take into account Hofstadter's Law. link
5 Estimation / time management Parkinson's law work expands so as to fill the time available for its completion link
5 Estimation / time management The 90-90 Rule The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. link
4 Estimation / time management Brooks's Law adding human resources to a late software project makes it later link
4 Estimation / time management Yerkes–Dodson law elevated arousal levels can improve performance up to a certain point link
4 Estimation / time management 5 laws of software estimates 1) Estimates are Waste
2) Estimates are Non-Transferable
3) Estimates are Wrong
4) Estimates are Temporary
5) Estimates are Necessary
link
4 Estimation / time management It's not possible to simultenously fix the cost, duration and quality of a software project link
4 Estimation / time management Lister’s Law People under time pressure don’t think faster. link
3 Estimation / time management Hartree’s Law The time from now until the completion of the project tends to become constant. link
3 Estimation / time management Vierordt's law retrospectively, "short" intervals of time tend to be overestimated, and "long" intervals of time tend to be underestimated link
2 Estimation / time management Amara's Law We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. link
3 Hardware Moore's law the number of transistors in a dense integrated circuit doubles about every two years link
3 Hardware Rock's law / Moore's second law the number of transistors in a dense integrated circuit doubles every two years link
5 Information The Law of False Alerts As the rate of erroneous alerts increases, operator reliance, or belief, in subsequent warnings decreases. link
4 Information Mooers's law An information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it. link
4 Information Segal's law A man with a watch knows what time it is. A man with two watches is never sure. link
3 Information Documentation is the castor oil of programming. Managers know it must be good because the programmers hate it so much. link
3 Information Chekhov's gun Remove everything that has no relevance to the story. link
2 Information Menzerath's law the increase of a linguistic construct results in a decrease of its constituents, and vice versa link
4 Management Putt's law technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand. link
4 Management Order of priorities: Functionality, Fidelity, Efficiency link
3 Management Cornuelle's Law Authority tends to assign jobs to those least able to do them link
3 Management Pournelle's iron law of bureaucracy In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely link
3 Management Kelly's laws 1) Power, understanding, control. Pick any two.
2) Nobody is as smart as everybody.
link
5 Measure Goodhart’s law When a measure becomes a target, it ceases to be a good measure. link
2 Networks Metcalfe's law the effect of a telecommunications network is proportional to the square of the number of connected users of the system link
2 Networks Dunbar's number 150 is the number of individuals with whom any one person can maintain stable relationships link
2 Networks Reed's law the utility of large networks, particularly social networks, can scale exponentially with the size of the network link
4 Problem solving Parkinson's law of triviality members of an organization give disproportionate weight to trivial issues link
4 Problem solving Sutton's law when diagnosing, one should first consider the obvious link
4 Problem solving Sattinger’s Law It works better if you plug it in. link
4 Problem solving IBM Pollyanna Principle Machines should work. People should think. link
4 Problem solving Occam's razor The simplest solution is most likely the right one. link
3 Problem solving Computers can never replace human stupidity. link
link
3 Problem solving Structural abstraction (not a performance problem) can always be solved by introducing a level of indirection link
3 Problem solving Shirky principle Institutions will try to preserve the problem to which they are the solution. link
2 Problem solving Augustine’s Laws 12) It costs a lot to build bad products.
17) Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics; i.e., it always increases.
23) Any task can be completed in only one-third more time than is currently estimated.
42) Simple systems are not feasible because they require infinite testing.
43) Hardware works best when it matters the least.
link
2 Problem solving Fitts's law the time required to rapidly move to a target area is a function of the ratio between the distance to the target and the width of the target link
3 Product Sowa's law of standards Whenever a major organization develops a new system as an official standard for X, the primary result is the widespread adoption of some simpler system as a de facto standard for X. link
3 Product Stein's law If something cannot go on forever, it will stop. link
2 Product Lehman's laws of software evolution 1) an E-type system must be continually adapted or it becomes progressively less satisfactory
2) as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it
3) E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal
4) the average effective global activity rate in an evolving E-type system is invariant over the product's lifetime
5) as an E-type system evolves, all associated with it, developers, sales personnel and users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.
6) the functional content of an E-type system must be continually increased to maintain user satisfaction over its lifetime.
7) the quality of an E-type system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes
8) E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.
link
2 Product Say's law Supply creates its own demand link
1 Product Reilly's law of retail gravitation customers are willing to travel longer distances to larger retail centers given the higher attraction they present to customers link
1 Product Sturgeon's law ninety percent of everything is crap. link
4 QA Pesticide Paradox If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs. link
3 QA Gilb's Laws of Unreliability Programming 1),Computers are unreliable, but humans are even more unreliable,
2) Any system which depends on human reliability is unreliable,
3) The only difference between the fool and the criminal who attacks a system is that the fool attacks unpredictably and on a broader front,
4) A system tends to grow in terms of complexity rather than of simplification, until the resulting unreliability becomes intolerable,
5) Self-checking systems tend to have a complexity in proportion to the inherent unreliability of the system in which they are used,
6),The error-detection and correction capabilities of any system will serve as the key to understanding the type of errors which they cannot handle,
7) Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.,
8) All real programs contain errors until proved otherwise -- which is impossible,
9),Investment in reliability will increase until it exceeds the probable cost of errors, or somebody insists on getting some useful work done
link
link
3 QA Heisenbug Uncertainty Principle A bug that disappears or alters its behavior when one attempts to probe or isolate it. link
3 QA Lubarsky’s law There is always one more bug. link
3 QA Wegner’s Lemma It is impossible to fully specify or test an interactive system designed to respond to external inputs link
3 QA Bugs lurk in corners and congregate at boundaries link
2 QA Linus's law given enough eyeballs, all bugs are shallow link
2 QA Premack's principle more probable behaviors will reinforce less probable behaviors link
3 Queueing Little's law The average number of customers in a stable system (over some time interval) is equal to their average arrival rate, multiplied by their average time in the system link
4 Requirements Humphrey’s Law For a new software system, the requirements will not be completely known until after the users have used it. link
3 Requirements Glass's law Requirement deficiencies are the prime source for project failures link
3 Requirements Ziv's law Software development is unpredictable and that the documented artifacts such as specifications and requirements will never be fully understood. link
3 Requirements Requirements end where the liberty of the developers begins link
5 Security / cryptography Murphy's laws If there is a wrong way to do something, then someone will do it. link
link
link
5 Security / cryptography Sod's law if something can go wrong, it will link
4 Security / cryptography Kerckhoffs's principle 1) The system must be practically, if not mathematically, indecipherable.
2) It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience.
3) Its key must be communicable and retainable without the help of written notes, and changeable or modifiable at the will of the correspondents.
4) It must be applicable to telegraphic correspondence.
5) Apparatus and documents must be portable, and its usage and function must not require the concourse of several people.
6) Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe.
link
4 Security / cryptography Finagle's law Anything that can go wrong, will—at the worst possible moment. link
3 Security / cryptography Ellison’s Law of Data The userbase for strong cryptography declines by half with every additional keystroke or mouseclick required to make it work. link
Security/ cryptography Schneier's law Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. link
5 Skills Dunning–Kruger effect Low performers are unable to recognize the skill and competence levels of other people, which is part of the reason why they consistently view themselves as better, more capable, and more knowledgeable than others. link
4 Skills Papert's principle Some of the most crucial steps in mental growth are based not simply on acquiring new skills, but on acquiring new administrative ways to use what one already knows. link
4 Skills Rosenthal effect / Pygmalion effect A general characteristic of human nature is that people tend to judge themselves, especially their competence and worth, based on the perception of others link
3 Skills Rothbard's law People tend to specialise in what they're worst at. link
5 Software architecture Liskov substitution principle functions that use pointers to base classes must be able to use objects of derived classes without knowing it link
5 Software architecture Postel's Law Be conservative in what you do, be liberal in what you accept from others link
5 Software architecture KISS keep it simple, stupid link
4 Software architecture Gall's law all complex systems that work evolved from simpler systems that worked link
4 Software architecture Tesler’s Law of Conservation as Complexity every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction. link
4 Software architecture DRY Don't repeat yourself link
4 Software architecture YAGNI You aren't gonna need it link
3 Software architecture Hyrum's Law With a sufficient number of users of an API,it does not matter what you promise in the contract:all observable behaviors of your systemwill be depended on by somebody. link
3 Software architecture Hoare’s Law of Large Programs Inside every large program is a small program struggling to get out. link
3 Software architecture A software system built on top of a weak architecture will sink due to the weight of its own success link
3 Software architecture Redundancy is a major source of errors... though it can also be used to reveal them link
2 Software architecture Zawinski's law Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. link
4 Software performance Amdahl’s Law The speedup gained from running a program on a parallel computer is greatly limited by the fraction of that program that can’t be parallelized. link
4 Software performance Spector’s Law The time it takes your favorite application to complete a given task doubles with each new revision. link
3 Software performance Eroom's law observation that drug discovery is becoming slower and more expensive over time, despite improvements in technology link
3 Software performance Wirth's law software is getting slower more rapidly than hardware is becoming faster link
3 Software performance Yao's principle the expected cost of a randomized algorithm on the worst-case input is no better than the expected cost for a worst-case probability distribution on the inputs of the deterministic algorithm that performs best against that distribution link
2 Software performance Andy and Bill's law new software will always push ahead of hardware and get credit for the performance of the computer link
4 Statistics Pareto principle for many events, roughly 80% of the effects come from 20% of the causes link
2 Statistics Benford's law in many naturally occurring collections of numbers, the leading significant digit is likely to be small link
3 Technology Melvin Kranzberg's six laws of technology 1) Technology is neither good nor bad; nor is it neutral.
2) Invention is the mother of necessity
3) Technology comes in packages, big and small.
4) Although technology might be a prime element in many public issues, nontechnical factors take precedence in technology-policy decisions.
5) All history is relevant, but the history of technology is the most relevant.
6) Technology is a very human activity - and so is the history of technology.
link
2 Technology Atwood's Law Any application that can be written in JavaScript, will eventually be written in JavaScript. link
2 Technology Maes–Garreau law most favorable predictions about future technology will fall within the Maes-Garreau Point, defined as the latest possible date a prediction can come true and still remain in the lifetime of the person making it link
2 Technology Clarke's three laws 1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
3) Any sufficiently advanced technology is indistinguishable from magic.
link
4 UX Jakob’s Law of the Internet User Experience Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. link
3 UX Hick's law The time it takes to make a decision increases with the number and complexity of choices. link