Eponymous Laws Part 2: Laws of Programming and Software Development
(See Eponymous Laws Part 1: Laws of the Internet)
Though ostensibly about programming and software development, most of these laws refer to fundamental aspects of human psychology (and folly). Enjoy.
Flon’s Law – “There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.”
Postel’s Law (aka Robustness Principle) – “Be conservative in what you send, be liberal in what you accept”… “In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.”
Bradley’s Bromide – “If computers get too powerful, we can organize them into a committee — that will do them in.”
Weinberg’s Law – “If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization.”
Hartree’s Law – “Whatever the state of a project, the time a project-leader will estimate for completion is constant.”
Hoare’s Law of Large Programs – “Inside every large program is a small program struggling to get out.”
Jakob’s Law of the Internet Use 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.”
Ninety-Ninety Rule – “The first 90% of the code takes the first 90% of the time. The remaining 10% of the code takes the remaining 90% of the time.”
Knuth’s optimization principle – “Premature optimization is the root of all evil.”
Linus’ Law – “Given enough eyeballs, all bugs are shallow.”
Kerchkhoff’s Principle – “In cryptography, a system should be secure even if everything about the system, except for a small piece of information – the key – is public knowledge.”
Wirth’s law – “Software gets slower faster than hardware gets faster.” (as a counterpoint to Moore’s Law)
Brooks’ Law – “Adding manpower to a late software project makes it later.”
Conway’s Law – “Any piece of software reflects the organizational structure that produced it.” Or…”Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
Eagleson’s Law – “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.”
(Originally posted at Secretum Secretorum)
This is no longer recommended for at least large, public APIs. Be conservative in what you send, sure, but don’t accept crap. Customers will depend on what you do, not what you say—if you accept things outside your spec, that becomes the spec, and makes it MUCH harder to change implementations or update usage at a later time without breaking users. The best time to fix a broken/sloppy client is before they make any successful calls to your service.
Give specific helpful errors for what you don’t accept.
The form I always heard the 90-90 rule in is: The first 90% of the code takes the first 90% of the time. The remaining 10% of the code takes the remaining 90% of the time.
[EDITED to add:] I see that the Wikipedia page about the 90-90 rule agrees with me :-).
Changed it to your rule, thanks for catching this—I think I might have just miscopied it or something.