Famous Laws of Software Development (2017)

I have always liked Postel's law (and Jon -- what a great human being he was) but I no longer like it as I used to.

The reason it's a really great idea is that it says you should engineer in favor of resilience, which is an important form of robustness. And at the same time, "strict in what you send" means "don't cause trouble for others.

However there are cases where "fail early" is more likely to be the right thing. Here are a few:

1 - Backward compatibility can bite you in the leg. For example, USB Type C (which I love!) can support very high transfer rates but when it can't it will silently fall back. So you could have a 40 Gbps drive connected to a 40 Gbps port on a computer via a cable that only supports USB 2 speeds. It will "work" but maybe not as intended. Is this good, or should it have failed to work (or alerted the user to make a choice) so that the user can go find a better cable?

2 - DWIM is inherently unstable. For users that might not be bad (they can see the result and retry) or terrible ("crap, I didn't mean to destroy the whole filesystem").

I see these problems all the time in our own code base where someone generates some invalidly-formatted traffic which is interpreted one way by their code and a different way by someone else's. Our system is written in at least four languages. We'd be better off being more strict, but some of the languages (Python, Javascript) are liberal in both what they accept and generate.

This aphorism/law was written for the network back when we wrote all the protocol handlers by hand. Now we have so many structured tools and layered protocols this is much less necessary.

Um, no. The real world is not that simple. It would be nice if it were.

Or perhaps your statement is correct, but in the real world components are never sufficiently separate. So, while your statement may be correct by definition, it is not useful.

Native English speaker, from England, and we were explicitly taught to use Brooks' rather than Brooks's.

However that didn't stop the Beatles from using "In an Octopus's Garden" as a song title. (Note that the song is about a single Octopus). I would suggest that it depends on whether you intend to explicitly repeat the 's' when speaking.

Plurals of words ending with an 's' are an occasional minefield. You sometimes hear people smugly insist that the plural of Octopus should be Octopi, only to have someone even more smugly point out that Octopus is from Greek, not Latin, and so it should be Octopodes. Meanwhile the rest of us just continue to use Octopuses....

Another of jwz's laws is:

Any social media company will expand until it behaves like a bank; receiving deposits and making loans to customers (not necessarily users).

The problem with the Knuth quote is that apparently people have turned the word "premature" into a synonym for "up-front." No, that's not what it means. Knuth is not saying that you should code (shit-out) the whole system naively and then try to find out where the bottlenecks are, as this dumb post suggests. Anybody that knows about the Knuth programming contest story would know he would be the last to endorse this. Premature literally means spending time on optimizing individual things before their need becomes apparent. It doesn't mean you should delay optimizing a system design from day 1.