Earlier quoted context omitted.
My favorite reason is: By definition nobody builds software that's ever existed before.
CRUD
I've worked on CRUD apps for my whole career, and I've never seen one that didn't have some novel requirements.
‘Laws’ of Software Development
41–50 of 74 posts
Re: ‘Laws’ of Software Development
#42Careful with Postel's Law: it brought us a lot the mess we have with web standards. 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.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…
Being liberal in what you accept is fine, iff strictly define the variations in the grammar.
Meredith and Sergey's outstanding talk about properly parsing all input discusses this update to how Postel's Law should be interpreted.
https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit
Re: ‘Laws’ of Software Development
#43Brooks' Law: "Adding manpower to a late software project makes it later."
Re: ‘Laws’ of Software Development
#44Careful with Postel's Law: it brought us a lot the mess we have with web standards. 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.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…
The other big problem with Postel's law is that it makes enforcing security guarantees a nightmare. When each component in a system is "liberal in what it accepts", it's very easy to fall into a trap where component A thinks that component B is performing the security checks and component B thinks that component A is performing the check and as a result the security check is either never performed or trivially sidestepped.
A good example of this was the vulnerability with null characters in SSL certificates [0]. 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.
Another example is with guarding against XSS vulnerabilities. Browsers try to be liberal in what constitutes valid Javascript, and will attempt to execute even the most malformed scripts they encounter. This makes it unnecessarily difficult to shield against XSS - one must block a whole range of vectors, rather than just script tags.
Re: ‘Laws’ of Software Development
#45Careful with Postel's Law: it brought us a lot the mess we have with web standards. 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.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…
Being liberal in what you accept is fine, iff strictly define the variations in the grammar. Meredith and Sergey's outstanding talk about properly parsing all input discusses this update to how Postel's Law should be interpreted. https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit
I would argue that if you're strictly defining the accepted variations in the grammar, then all you've done is define a new grammar that you're conservatively adhering to. And that's fine! There's no rule that says that standards cannot evolve to match new use cases. However, I would argue that having a strictly defined (yet evolving) standard is much different than the common interpretation of Postel's Law, which is that undefined behavior should "do the right thing", with the specific interpretation of "the right thing" being left to the implementers. Predictably, different implementers interpret that in different ways, which leads to security holes. But if the specification defines what the right thing to do is, then the behavior is no longer undefined, and therefore Postel's Law no longer applies.
Re: ‘Laws’ of Software Development
#46~~laws~~ rules of thumb
Re: ‘Laws’ of Software Development
#47the more complex a software system is, the more the people not involved in its creation will criticize the colors and placement of buttons on the UI.
bikeshedding
Re: ‘Laws’ of Software Development
#48Atwood: "Any application that can be written in JavaScript will eventually be written in JavaScript"
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%"
Re: ‘Laws’ of Software Development
#49One of my favorite quotes -ever-: 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
It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away. — Antoine de Saint Exupéry
Re: ‘Laws’ of Software Development
#50Missing some big ones: 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." https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la... Conway's Law: "organizations which design systems ... are constrained to pr…
There are many other laws, e.g.:
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.
Atwood's Law: Any application that can be written in JavaScript, will eventually be written in JavaScript.
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...