I have previously discussed how important the environment is in creating meaningful behavioral change. I’ve also suggested that the developer’s IDE (or Integrated Development Environment) was an influential source of positive behavioral prompting. If we move beyond just the single IDE, the software development pipeline could also be an environment capable of prompting desirable outcomes. This process is known as The Golden Path.
Charity Majors is the co-founder and CTO of Honeycomb, makers of code observability software. She describes the Golden Path like so:
“Tell all your engineers that going forward, the Golden Path will be fully supported by the org. Upgrades, patches, security fixes; backups, monitoring, build pipeline; deploy tooling, artifact versioning, development environment, even tier 1 on call support. Pave the path with gold. Nobody HAS to use these components … but if they don’t, they’re on their own. They will have to support it themselves.”
For all but the smallest of dev shops, there are advantages to having centralized processes and infrastructure. “Approved” tech stacks are standard to ensure proper staffing and triage is possible. A single log standard can save copious amounts of time and effort when in the thick of an outage.
Traditionally, governance - either in the form of an Architectural Review Board, Center of Excellence, or some other bureaucratic entity - dictates the software development behaviors they expect others to follow. An example might be “We are a Spring Boot and Node shop” or “Every new service must implement Open Tracing”. The bulk of energy is then expended on detection and enforcement, which - honestly - is probably not how anybody dreamed they’d be spending their productive waking hours. (The lack of of career development path for this work is a topic for another post; all too many enterprises end up parking their most passionate system thinkers into these professional cul-de-sacs.)
Instead, employing a Golden Path strategy directs that energy to create a superior developer experience. Sure, each team that needs to make an API could select, configure, and operate their own API gateway. They could roll their own authentication and key provisioning server. They could customize their own CI/CD pipeline. But if there is a platform team providing a well-supported, consistently performant, and feature-compatible equivalent, why would they? And some point, the novelty of tinkering with configuration files wears off, and a realization sets in: dithering with non-differentiating technology is not the same as delivering business value.
Creating a Golden Path is work. However, suppose you can create an environment where doing the right thing is the easy thing. In that case, you are significantly further along than relying on best faith efforts and goosing external incentives.
Update 2022-05-05
Along these same lines is Yunong Xiao’s 2017 presentation entitled, “The Paved PaaS to Microservices at Netflix”. “Paved Path” is the same concept as “Golden Path”.
