Why Standardisation Matters
Standardisation matters. It’s one of those things that often gets discarded in the pursuit of ambitious targets, and in my experience a loss of standardisation across an org is one of the most crippling types of Technical Debt. Below I’ll discuss why it’s important, and explain what happened when we drifted from standardised CI/CD pipelines.
Why Standardisation is Important
Everyone appreciates the ideals behind a whole organisation adhering to a standard, but inevitably some drift trickles in. We might start from a common template, but use cases evolve, team processes change, and in no time at all the pristine project template everything started from doesn’t actually reflect the reality of any system in production.
We tell ourselves that it would be nice to have common standards that make it easy to switch between teams, but realistically, how often are people going to move? Besides, it’s only a small difference…
Before we know it, we have two different teams working in the same languages with fundamentally different project structures, both perfectly happy with their own structures, but now enacting the same change on both of those teams' projects at once is no longer a simple job; both teams need bespoke solutions, and those bespoke solutions will take time from the team, rather than anyone else being able to do it for them.
This is the real reason why Standardisation is important: it’s about being able to solve common problems once.
Example: Migrating “Standardised” Pipelines
To take a relatively straightforward example, recently we’ve been looking at migrating CI/CD platforms. I won’t go into why; it doesn’t really matter. Teams change, tools change, usage changes - no matter what platforms you choose, it’s almost inevitable that you’ll need to migrate onto a new platform for something in your time in any organisation.
Migration should have been relatively straightforward. Our repos are largely all build from common templates, with CI/CD pipelines built in. Just a matter of building a simple script to migrate the templated, standard pipeline to the new pipeline, right?
Wrong.
It turns out most teams customised the templated pipeline to suit their specific team process, and very rarely fed the changes back into the templates, even when it was a relatively common requirement. This meant that the automated scripts we built for migrating only worked for the ~33% of pipelines that had been left at the standard configuration.
What’s worse, even though the pipeline modifications were fairly standard across teams (different teams needed similar changes), the implementation wasn’t the same; each team had chosen to solve the problem in their own specific way. So we couldn’t build one script that would migrate all of these modified pipelines, even if they essentially did exactly the same thing. Frustrating!
In reality, this is a super common problem; leave a group of clever people to solve a problem, and they are as likely to come up with their own solution as they are to ask “has anyone already solved this?” We like solving problems, it’s a great strength of most Software Engineers, but cleverness and the desire to be the one that solves the problem is very much a double-edged sword.
A Better Way: Evolve the Standard
In an alternate reality, when teams had realised that the template didn’t suit their needs, they raised the issue with the Platform team (and the other Tech Leads), and proposed a change to be made by the template owners.
Or, they made the change, and showed the other teams how it worked.
Or, they raised a PR against the template and asked for a review from the owners.
In any of these scenarios, when another team then needed the same functionality, they could use the existing standard method rather than coming up with their own version. Then, when the inevitable migration came about, the Platform team would have been able to script a migration path for every team, and every pipeline, dramatically reducing the effort for each team, and allowing testing to give confidence that migrations will run without a hitch.
So the next time you’re in a team proposes a drift from a standard model, ask whether:
a) anyone else in the company is trying to do a similar thing, and
b) can we adjust the standard to cater for this variant?
In doing so, you might save you and your colleagues an awful lot of trouble when you need to migrate it in the future!
In Summary
Standardisation isn’t about enforcing sameness for its own sake; it’s about making future change predictable, safe, and fast. When teams drift from shared patterns, every improvement becomes harder to deliver and harder to benefit from. But when we keep the standard alive and evolving, we get the opposite: lighter migrations, fewer surprises, and more time spent solving real problems. Fight for your standards, keep them clean, and the effort involved in keeping them up to date will more than pay itself back when you need to apply a common change in future.