Me: Have you got a standard for this?
Him: Sure, we love standards! In fact, we’ve got two!
As discussed in reducing surprise, it’s better to have a standard, that to have to explain why things are different to each other. There is a difficulty with standards, though.
In many projects I’ve been on, I’ve been highly motivated to use the standards of the systems I’ve integrated with rather than try to create a perfect model for everyone to follow. This is because you can’t get everyone to agree on a single model, in practice, and a perfect model can create a resistance to change if everyone has to agree on it, and adopt it as it grows.
There are some great solutions out there for models which tolerate evolution without committing their consumers to constant upgrade, but that’s a subject for another day.
When it comes to internal standards, though, the question is whether the same rule applies. If your own application for its own processes has a there’s more than one way to do it policy, is that ok?
What’s a Standard For?
Standards allow you to reduce the amount of complexity in a series of things that are related by setting rules that enable you to predict what happens in each place those related activities/data are found.
Something as simple as a different field name, or a different capitalisation standard, or a different format can produce a huge amount of code to transform between corners of your system, and can make the developer who moves from one component to another a constant stranger in a strange land.
Conversely, having a single internal standard can accelerate development and make anomalies easier to spot.
That said, integrating with external systems on their terms is always a good way to build bulkheads between potentially changing interfaces, and earn trust.How having a single standard is easier than explaining the subtle differences between variants. Example export format one for import and export format two for reporting.