Respect the Data

From Zanecorpwiki

In developing, good data is sacrosanct. You can't control what data comes in, so this means ensuring that only good data gets stored because once "inside" the application, the data is trusted. It's possible to distrust internal data, but there's no point because whatever checks and verification can be done could have been done on the data as it entered, so why not do it there and simplify things?

This means unless data can be understood, it must be rejected and the current process should fail. By taking the "screen on entry" approach, this limits such failures to input errors. Whether it be user or third party, the app essentially says, "Hey, this is garbage, try again."

The other side of the coin is that functions on data already on the inside should never fail for due to faulty data. The fact that the data exists behind the app means the data is good.

This is why open backends are so problematic. Anything can fail at any time.