Conway's Law - the technical boundaries of a system will reflect the structure of the organisation

Gall's Law - A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

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

Hutber's Law - Improvement means deterioration.

Hyrum's Law (The Law of Implicit Interfaces) - With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody.
	(Eventually, someone is going to do something weird with your game which will break it.)

Premature Optimization Effect - Premature optimization is the root of all evil. (Donald Knuth)
	Do not underestimate the wisdom of Donald Knuth. Likewise, write dirty, edit when you're done.

The Law of Conservation of Complexity (Tesler's Law) - There is a certain amount of complexity in a system which cannot be reduced. The full, relevant text and conclusion:
	Some complexity in a system is 'inadvertent'. It is a consequence of poor structure, mistakes, or just bad modeling of a problem to solve. Inadvertent complexity can be reduced (or eliminated). However, some complexity is 'intrinsic' as a consequence of the complexity inherent in the problem being solved. This complexity can be moved, but not eliminated. One interesting element to this law is the suggestion that even by simplifying the entire system, the intrinsic complexity is not reduced, it is moved to the user, who must behave in a more complex way.

The Law of Triviality - Groups will give far more time and attention to trivial or cosmetic issues rather than serious and substantial ones.
	Don't spend too long arguing about kerning or dice notation.

The Unix Philosophy - Software (TTRPG system) components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs.

The Pareto Principle (The 80/20 Rule) - Most things in life are not distributed evenly.
	20% of your material is going to generate 80% of the arguments/confusion/nonsense. Focus on fixing that.

The DRY Principle - Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
	DRY stands for "Don't Repeat Yourself". The opposite of DRY would be WET (Write Everything Twice or We Enjoy Typing).

The KISS principle - Keep it simple, stupid
	Specifically, "keep it simple AND stupid". You're not calling the writer stupid; make it simple enough to be used when the dice are flying, everyone's a little tired, and you'd lose momentum if you had to spent 10 minutes parsing a paragraph of rule text.

YAGNI - You Aren't Gonna Need It. "Always implement things when you actually need them, never when you just foresee that you need them." (Ron Jeffries)