Planned Difference: Consciously diverging from standards

Whenever there is a standard within a company, it most certainly will not fit with any and all use-cases. Additionally, there might be cost optimizations, especially local minima, for looking outside the standard. This is all perfectly fine, and challenging the status quo should be part of any healthy business culture.

But what sometimes seem to happen, is divergence from the standard in a seemingly random fashion. And the standard itself might erode to the point where the is in fact no standard at all. Which brings us the problems standardization itself was meant to solve! Maximize compatibility, interoperability, safety, repeatability, or quality. For software engineering, I would also offer another key element of standardization: reduction in cognitive overhead.

Enforce one standard, and only one standard, everywhere, all the time. Problem solved?

I would like to offer an alternative. A guiding principle. “Planned Difference”.

I was recently exposed to a discussion on cost saving for storage of large files. It was proposed to use a different backend for storing these, because the file in question exceeded the free quota of the existing system. The file that triggered the discussion was 20GB, which exceeded the quota of 10GB. While the total storage of the solution was 3TB, files are generally below 10GB in size.

From a pure technical point of view, simply uploading this file to some other system is trivial. It’s done in 2 minutes. Problem solved. And it’s often quite an attractive option. This is largely related to the fact that any sufficiently complex organization will include some non-trivial things before spending company money.

But from a company perspective, securing and auditing access to files, documenting where the relevant files can be found based on seemingly arbitrary properties, backup, implementation in deployment pipelines, vulnerability and license scanning, firewall and proxy allow lists, vendor contracts and supply chain security adds up! You might end up spending a lot more company resources than you save.

The keyword here is “might”. When diverging from the standard, make it a conscious decision! Divergence should have a very specific reason and be a planned divergence. Not purely because of convenience in the moment. If you have a need for specialized technologies not covered by standard solutions, or have specific regulatory requirements which cannot otherwise be fulfilled, implementing this outside the standard would be perfectly okay.

Divergence is also not the only approach. Standards needs to be kept up to date and relevant. There might be a great innovation potential in redefining or significantly improve upon the standard itself. If the standard consistently under-performs or fails to meet the required efficiency or productivity levels, the standard itself should be challenged.

If your need falls within a common process, routine tasks where standard solutions have proven efficient and effective, or falls into established best practices where deviation can introduce significant risk:

Stick with the standard as the default!