This is part of a sequence of posts on engineering principles.
What is Postel's Law?
Postel's Law (also called the robustness principle) was popularized by Jon Postel in 1980 in an RFC as a core tenet of the design of the transmission control protocol (TCP), which underpins the modern internet. It goes like this:
[One] should follow a general principle of robustness:
be conservative in what you do,
be liberal in what you accept from others.
Simply put: you should hold your systems to a high standard, and ensure they do what they claim. At the same time, you shouldn't expect everyone else (or indeed anyone else) to meet that standard. This is one of those engineering principles that has nice real world analogies - it's not far off from "treat others as you would like to be treated," but for computers.
How does this work in practice?
Postel's law is one that can be applied at the very small scale (like when thinking about how to design a single function, and how to reason about inputs that you may not control), or at the very large scale (like when thinking about how to design a communication protocol that underpins the internet, or an API that many developers will use). Most engineers start their career applying it in the small, and grow towards the larger applications. One of the primary advantages to my mind is that expressing your contract this way allows you to take ownership of correcting issues. If you insist that others meet the letter of what they've committed to, in practice when they do not your only real recourse is to try and get them to do what they said they would do. You run into organizational issues - maybe solving the problem perfectly to spec isn't a high priority for them, or not as high as it is for you. When you resolve to be liberal in what you accept (though conservative in what you produce), you take ownership over the problem. You can work with their outputs (even if imperfect), and do work on your system to arrive at the desired outcome even in the face of imperfect building blocks.
There's a real secret here that I've learned over time, which is that generally outcomes are prioritized over means, and few people really care about the rational behind missed expectations. It's a far better organizational move to focus on delivering some degree of even incremental value, than to say "I was blocked because another team/person/company didn't do what they said they would do." While it's true that sometimes you really can't work around blockers like that, most of the time if you relax your expectations and think outside the box you can make some progress towards whatever your starting goal was, even if it's not perfect, when you allow yourself to build "incorrect" solutions that work around the shortcomings of other systems.
