gui-text / empirical-laws-of-software-development

Empirical laws of software development

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