This is another tech nerd post. Normal humans seek cover!
Abstract: Fail loudly and immediately.
(I sure hope all the normal humans took cover already because that sentence sure would sound different to them than to us! I also hope this isn’t all too obvious for actual programmers but I predict you’ll see it violated plenty and maybe this post will be useful to point people to.)
The Robustness Principle, also known as Postel’s Law, says to be conservative in what you send and liberal in what you accept. I don’t think I’m alone in opining that that principle makes web development a Lovecraftian nightmare. The misguided, myopic monition from Postel  is, ironically, the single biggest cause of me saying “this is why we can’t have nice things”. On the internet anyway.
What you should actually do is fail hard and loud and consistently and make everyone get with the program. Everyone (or thing) interacting with your program, I mean. It’s kind of the API version of the Anti-Magic Principle.
Code-philosophically, when a program gets input that’s slightly wrong but it’s easy to convert it to what you know the input was meant to be, it’s a Very Bad Idea to actually do that. Instead you should say “that input is Not Exactly Right so everything will break now”. It sounds crazy but is so, so true! Being forgiving leads to cruft and technical debt and baffling future bugs. Again, I’m not being particularly contrarian here. See the Criticisim section of the Wikipedia page on the the Robustness Principle.
“Make your code overly literal and punctilious and pedantic”
Now we come to the shameful part where we tell you how we’ve learned this the hard way. Actually we’ve learned and relearned it embarrassingly many times over. Keep code dumb, for God’s sake. I mean your future self’s sake. God can handle clever code just fine. For us mortals, it’s going to break in every imaginable and unimaginable way regardless and the dumber it is the easier it will be to debug.
And by dumb I mean simplistic. Exemplify every obnoxious nerd stereotype: Make your code overly literal and punctilious and pedantic. Even obtuse, in the sense of making zero assumptions, as the listener, about what the speaker intended.
Here’s a specific way we ourselves have violated this principle: The Beeminder API, if it gets a parameter it doesn’t recognize, silently ignores it. Anguished wail! That just means if you misspell something then everything will appear to be fine and later it will turn out to be mystifyingly not fine and unless you get lucky and spot the mistake you may end up heaving your computer out the window and that is expensive. It actually seems absurd to me that we didn’t know that back in 2012, but here we are.
Can’t we just fix it, you ask? Maybe not! And this is the real kicker with how awful the Robustness Principle is. Or how vital the Anti-Robustness Principle is. Since the Beeminder API is all nice and forgiving about unknown parameters, who knows which clients (including our own smartphone apps, though we could fix those ourselves, obviously) will break if we suddenly stop being misguidedly robust.
If you do the persnickety thing you can always change your mind later and be more forgiving. It’s much harder to go the other direction. Hence Anti-Robustness being an important guiding principle for writing code and us consecrating it as a blog post in hopes that we’ll be better about this ourselves.
Image credit: Faire Soule-Reeves