The precepts in this group are the design rules of computing, most of them written by engineers who learned them from failure. They cluster around three concerns: keeping systems simple, keeping them secure, and deciding what machines should do for people. Several of them contradict each other when taken to extremes, and knowing where each stops applying is most of the craft.
Keep it simple, and compose
The largest cluster argues for simplicity. The KISS Principle prefers the simplest design that meets the requirement. The Unix Philosophy asks for programs that do one thing well and work together through simple interfaces. Lampson's Hints for System Design set the order of work: make it simple, make it right, then make it fast. YAGNI, you aren't gonna need it, warns against building for requirements that have not arrived, and the Rule of Least Power prefers the least powerful language that will do the job, because what it can express can be analysed.
Keep it secure
The security precepts are older than computers in one case and foundational in the others. Kerckhoffs's Principle, from 1883, holds that a cipher should remain secure even if everything about it except the key is known, which is why modern cryptography is published and tested openly. The Principle of Least Privilege gives every component only the authority its task requires, so that one compromised part cannot reach everything. The End-to-End Principle, which shaped the internet's design, puts functions that need application knowledge at the endpoints rather than in the network.
What machines should do for people
Two precepts ask a different question. Engelbart's Augmentation Principle, from 1962, calls for tools that raise human capability in partnership with their users rather than replacing them; it led to the mouse and hypertext. Asimov's Three Laws of Robotics were written as fiction, and his stories are mostly about how such rules fail, but they remain the starting point for public discussion of machine ethics.
Where it applies
These rules are daily working practice in software engineering, and several apply well beyond it. Least privilege is standard in security policy for organisations, not only for code. Kerckhoffs's principle argues against any security that relies on keeping its design secret, including in physical security. The end-to-end principle explains why the internet has been so open to new uses, since the network does not need to understand them. Engelbart's framing is increasingly relevant as organisations decide whether to use AI to augment staff or replace them.
Where it is argued over
The rules pull against each other in practice. The DRY Principle, don't repeat yourself, encourages shared abstractions, while YAGNI and experience with leaky abstractions warn that premature sharing ties unrelated code together; many engineers now accept some duplication rather than the wrong abstraction. The end-to-end principle is argued over whenever performance, security filtering or content moderation would be easier inside the network. The rule of least power, taken too far, produces formats that grow ad hoc extensions until they are powerful anyway.
Why it is worth knowing
These precepts are how engineering judgement is transmitted, and they apply to any complex system people build, from software to organisations. Each one records a lesson about what goes wrong when a system grows too clever, too trusting or too eager to do everything. Knowing them together, including their conflicts, is what separates following a rule from knowing when it applies.
The entries behind this essay: Precept in Technology & Software. Every subject has its essays on the essays page.