Via Stefan Tilkov I came across this Mark Baker article and well I'm going to set myself up on the opposite side of the fence here, in fact I'm going to go over that fence, across the field and sit in the pub watching him sink slowly into a quagmire.
One of the worst things I see in IT over and over again is the rage against formalism and verification, its just bizarre how often it happens. Now Mark might have a great new idea for time dependent evolvable validation... but for me he is wrong in principle.
First of all lets start with a the basic tenant that everyone should hold dear
KISS - Keep it Simple Stupid
And another is one of the few new Agile terms that I liked which formalised an age old saying
YAGNI - You aren't going to need it.
And before I get into it also have a look at The second System effect from the best book in IT.
When dealing with 3rd parties a basic rule of thumb is trust no-one and CYA (Cover your ass) this means verifying both what you send out as well as verifying what you receive. There are very good engineering reasons for this. Lets say that you have said that there is a limit of two items per order, as that is the business decision. If someone sends 2344 you want to reject that straight away, and schema verification is a great way to do that.
Engineering means designing a system that works for the task it is required to do, and if one of the things it needs to do is allow change then it needs to allow that change in a controlled and measured way.
The concept that Mark puts forwards of validating only at the last possible moment is somewhat beguiling as it has the idea that everything will turn out right, but if the poor bugger on the order system is expecting massive numbers then the odds are he won't have coded it expect them. This isn't their fault, if you say "its 1 or 2" then its pointless him writing loads of code to handle a million items.
Validating at the edges however does require you accept that when change happens it may break things. But the reality is that most of the time this is what you want. if you are dealing with someone who suddenly sends in a new document with a field that says "by responding to this message you are agreeing to give us all your money and your first born child" then you'd like to know.
Validate as early as possible, make sure that things are correct and hold people to account as early as possible. I've seen companies lose literally millions of pounds (billions of dollars :) because they didn't enforce interface contracts effectively, this led to problems down the line and systems that were very hard to untangle.
There are an awful lot of stupid people out there and it is your job to protect your systems and your business from their stupidity, this means not trusting what they sent you and checking it yourself for validity. Optimism is not a good engineering trait, pessismism is. That is why you validate what you send to make sure it doesn't come back on you, and validate what you receive to make sure the other person isn't an idiot.
To use a physical engineering analogy, you check that the wing is put on properly as soon as it is attached, not by looking out of the window at 30,000ft to see if it is still there.