The idea of production parity in development environments gets thrown around a lot. Making development environments more like production has some objectively useful aspects:
However, everything has a price. Production parity doesn’t exist in a vacuum, and making development behave more like production often means running heavier-weight tools on development machines than would otherwise be necessary. Heavier tools inevitably slow the developer’s core workflows, which has less-apparent impacts on reliability and even overall product velocity.
In working on tooling for the better part of the last decade, I’ve observed that the number of errors arising out of divergence between development and production is lower than most people intuitively feel it should be: CI tends to catch most things that developers don’t, and canary deploys where available should catch the rest.
Conversely, it’s hard to imagine how we might measure the consequences of improvements or regressions in developer workflow delays, but I think everyone should be able to wrap their heads around how this is, in fact, A Thing.
My core point is: