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."
Conway's Law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
Cunningam's Law: "the best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer"
Zawinski's Law of Software Development: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
But there is perhaps no greater legal scholar than Norman Augustine:
Law XVI: Software is like entropy. It is difficult to grasp, weighs nothing and obeys the Second Law of Thermodynamics: i.e., it always increases.
Law XXX: The optimum committee has no members.
Law XXXV: It is true complex systems may be expensive, but it must be remembered that they don't contribute much.
Much recommended: http://www.amazon.com/Augustines-Chairman-Lockheed-Corporati...
Performance is a constraint, not a goal.
Do what is simplest, and remember, everyone is attacking you with stupidity. Most of your simple work will be done quickly, a small amount will be done in the time remaining. You will think you are better at doing all this than you are. To wit, seek the help of others to talk you down-- accept things from others. You'll need it because eventually you become a stranger even to yourself. And from there you'll rise to the level of stupidity you detested not too long ago. Or maybe some unwise fool will intercede on your behalf, dragging you up to their level of idiocy. This will all take longer than you think, because all along the way you underestimated your skills, but don't worry there'll be plenty of work to fill the time. Most of it will be petty, and you'll fight over the least essential things, but that's because you chose to work in a field full of smart people who continually underestimate their abilities.
Seems to make more sense given "we think we are better at doing this than we are".
Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle:
In RFC 3117, Marshall Rose characterized several deployment problems when applying Postel's principle in the design of a new application protocol. For example, a defective implementation that sends non-conforming messages might be used only with implementations that tolerate those deviations from the specification until, possibly several years later, it is connected with a less tolerant application that rejects its messages. In such a situation, identifying the problem is often difficult, and deploying a solution can be costly. Rose therefore recommended "explicit consistency checks in a protocol ... even if they impose implementation overhead".
A good example of this was the vulnerability with null characters in SSL certificates . In that vulnerability, both the browser and the certification authority interpreted the domain with the null character as "liberally" as possible, but their differing interpretations of what constituted "forgiving" made it trivial to spoof SSL certificates merely by including a null character in your domain.
Engineering with unspecified bounds often needlessly introduces complexity and cost.
Meredith and Sergey's outstanding talk about properly parsing all input discusses this update to how Postel's Law should be interpreted.
Perhaps it's better to use this law for UI, where being liberal with accepting things by trimming white space is better than rejecting, which would confuse an end user.
The common appearance of the ignorant user seems to stem from him generalizing patterns as a holdover from one UI to another. Perhaps we should better study these patterns and steer the user to a consistent path. But instead, it seems we're trying to out-smart him time and time again, creating a jungle of user interactions which merely belittle and confuse.
Not so okay when dealing with input created by programs.
And as you said totally not okay when dealing with protocols, encryption, and authentication. See padding attacks.
The standards compliance check evaluates if a given program or module complies with the written standard. The reference implementation is free to be more fault tolerant or otherwise assume that invalid input is allowed to produce undefined results (as long as they are not clearly the wrong behavior).
Related to the Peter & Dilbert Principles, but darker and told through the lens of the Office.
In a corporate hierarchy are the losers (bottom), clueless (middle), and sociopaths (top).
Losers: Economic losers in that they prefer a fixed monthly paycheck over their fair share for their contribution. Risk-averse. They know they made a bad deal and don't do more than expected. They play social validation games with each other to feel better in order to stand their fate.
Clueless: They believe in the corporate story and work more than they're payed for. They're promoted into middle management where they serve as a buffer between the top management (sociopaths) and the workers (losers). They execute all ideas from top management, from the stupid over the risky to the good. If something succeeds, the sociopaths take the credit. If something fails, the clueless take the blame.
Sociopaths: Nihilists who emotionally broke under the realization that no true values exist in this universe, so they're free to make values and goals up as they like. Those stories are given to the clueless to believe in. In every corporate life cycle exist different sociopaths. In the beginning they're the risk-takers with a vision and the willpower to push something new through. In established companies they kill off new and threatening ideas to protect the successful products. During decline they milk the company for the remaining values, then leave the sinking ship and hand responsibility over to the clueless to let them take the blame.
One important part are the different languages of the three classes. Losers have "game language", the social games they play to validate each other, but the talk and the content are unrelated to reality and don't advance them in the hierarchy. The clueless try to speak like the sociopaths but don't realize that one has to have stakes in the game (i.e. something to lose or something valuable to offer) in order to be taken seriously, so their language is full of empty phrases and threats. The sociopaths' "power talk" is full of hints (without commitments) that are only understood by equals and when they talk about something they have to lose or gain something -- it's about the real things, not the empty phrases the clueless use.
Any intelligent fool can make things bigger and more complex...
It takes a touch of genius - and a lot of courage to move in the opposite direction.
E. F. Schumacher
90% of this list is crap -- https://en.wikipedia.org/wiki/Theodore_Sturgeon
A programmer can accurately estimate the schedule only for
the repeated and the redundant. Yet,
A programmer's job is to automate
the repeated and the redundant. Thus,
A programmer delivering to an estimated or predictable schedule is...
Not doing their job (or is redundant).
For any given reasonable estimate for an item of software, add 2^N days to that estimate, where N = the number of date/datetime fields involved on that form or database table.
eg - You have a complex data entry screen to add to a webpage, and you KNOW for certain that you can complete it thoroughly in 2-3 days tops, testing every possible edge case. Good stuff.
However, if that screen has 2 date fields involved, then its going to take 2^2 or 4 extra days over and above the reasonable estimate to get it done properly, and handle NULL dates, timezone differences, comparison of dates for equality, parsing date inputs, converting internal representations between front end / backend / storage ... and every other unexpected abomination.
Sometimes (oftentimes, in my experience) they really do hate you.
Sometimes assuming just a tiny bit of malice can account for layers and layers of presumed stupidity.
Zawinski: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." s/mial/API etc
And I can't find this one (IBM study?) "Adding 10% of features increases cost by 100%"
Too bad the inverse isn't true. Would be nice if we could cut costs by 100% just by ditching a tenth of the features.
Good software will grow smaller and faster as time goes by and the code is improved and features that proved to be less useful are weeded out. [from the programming notebooks of a heretic]
If I were to quote the above to a layman--someone well outside the world of software development--the response would be, "Well of course that's what would happen, it's obvious."
Model checking in particular, in my limited experience using it, is effective at this.
You can eliminate many (not all... nothing's perfect) of these rules of thumb with a little math and analysis.
Note also that some "laws" may remain as "laws", even in the face of experimental evidence which directly contradicts the predicted results of that law.
Which gives rise to "The Law of Research Funding", in which the amount of funding that can be attracted to support a given law is proportional to the amount of real world experimental evidence which contradicts that law. :)