13 Software Engineering Laws and Their Implications

Parkinson's Law: work expands to fill the time available.

Hofstadter's Law: tasks always take longer than expected, even when you have accounted for the law.

Brooks' Law: adding manpower to a late software project makes it later.

Conway's Law (and its inverse): the design of a system mirrors the communication structure of the organization that creates it.

Kenneth's Law: the best way to get the correct answer on the Internet is not to ask a question but to post an incorrect answer.

Sturgeon's Law: 90% of everything is garbage.

Zawinski's Law: every program tries to expand until it can read email; programs that cannot are replaced by those that can.

Hillel's Law: when an API has enough users, the exact contract matters less because all observable behavior will be relied upon by someone.

Price's Law: in any group, roughly the square root of the total number of people produce 50% of the work.

Lingerman's Effect: individual productivity tends to decline as the size of the group grows.

Goodhart's Law: when a measure becomes a target, it ceases to be a good measure.

Gilb's Law: anything you need to quantify can be measured in some way, which is better than not measuring at all.

Murphy's Law: anything that can go wrong will go wrong.