Cognitive Load Is The Mind Killer

The term “A Golden Path” is not new to us, though there’s lots of different names for it. The Happy Path, The Blessed Path, Approved Software, Software Shopping List, Standardisation. All of these describe the same thing: A set of supported software/processes/things that are already well-understood and in-use.

I like the term Golden Path, purely aesthetically, because I think it best describes the concept in just a couple of words.

Aside: I’m also a nerd, and nerd’s like references. “The Golden Path” is a reference to Dune and the God Emperor’s ability to see into the future. “The Golden Path was an expansive prescient interpretation […] It revealed an optimum path through the countless threads of cause and effect.”

I’ve Got Opinions!

Don’t we all…

In software engineering, the Golden Path is all about opinions and assumptions in a company. As we grow as engineers and organisations, we build opinions on how to write, build, test and deploy code. We build opinions on how to monitor our applications, and what to monitor. We choose database paradigms and compute layers. We build an ecosystem of opinions.

A Golden Path is about formalising all of those opinions and turning it into a deliberate process so that we can narrow the cognitive load infrastructure and platform teams have to shoulder, and offload that cognitive load from product teams. Every new language, framework, technology and process puts cognitive load somewhere, and choosing a Golden Path acknowledges and codifies who and where that load should be.

Over the lifetime of a company, we let a 1,000 flowers bloom, and there comes a point where we to have to rip 999 out by the roots.

Why Follow The Yellow Brick Road?

1. Reduced cognitive load: Teams can focus on supporting less, and stop being jack of all trades, which frees up time to…

2. …Build expertise: Teams get the opportunity to stop building generalised software, and instead focus on building expertise in their domain, which leads to…

3. …More automation: With assumptions, teams can observe common patterns and automate the needs of our service throughout its lifecycle, which results in…

4. …Faster iteration: We can build out templates and frameworks that fit how we expect software to be built, which means we get everything we need in one handy box, on demand, whenever we need it

What If I Don’t Like Our Opinions?

With the Golden Path, we are still free to use whatever technology stack we want, and build with what we’d like… We just won’t be necessarily be able to shed the cognitive load of supporting that stack off to other teams.

The Golden Path, ironically, is not set in stone. We understand that what we create and choose right now, will not stand the test of time. We can’t see into the future, that’s not the point of this. We’re not sitting down to outline the technology stack we will use forever. We’re sitting down to determine the best stack to support right now.

We’ll need to make changes, adopt new technologies, techniques and cultures. But we need to do it deliberately, and make explicit choices.

Adding or changing bricks on the path should still give us the 4 benefits from above, so we need to be quite thoughtful about how we change the path.

Example: A Delivery Golden Path

I am Evan and I manage a Delivery Engineering team. We manage the CI/CD ecosystem and how software is built and released. So it’s the easiest domain for me to use as an example.

There’s a lot of scope in a delivery process for Golden Paths, below are 6 “pillars” of decisions to be made. Each of these pillars needs a technology, processes, best practises and standards. Any one of these is a whole domain of expertise unto itself, but it’s our job to tie them all together into a pipeline suitable for the company (and not burn ourselves out doing it).

1. Version Control

2. Pipeline Configuration

3. Continuous Integration

4. Release Tools

5. Code Analysis

6. Artifact Storage

7. Continuous Delivery

Making Example Decisions

If we filled out those 7 pillars with decisions, it might look something like this:

View fullsize

Aside: Important to note here that this isn’t exhaustive, just illustrative. This doesn’t represent any particular company or team I work/have worked with. I just chose some popular products and technologies to flesh it out.

The black boxes represent the start and end state of our code.

The yellow boxes are one of the pillars I mentioned above.

Each of the pink boxes are a decision made by this imaginary Delivery Team.

Everything from tiny decisions like storing our pipeline configuration as code, all the way up to big decisions like deploying all software with Blue/Green deployments, or with Canary versions.

Notice how all of the pink box lists start with a tool name, in bold. Each of the decisions beneath the tool are tied to that tool.

Now, imagine if had to support one more tool for Step 03: building releases. Let’s pick NPM and commitzen. We have to figure out how these tools do automatic versioning, and some way to automate our container security scanning process. Okay, we’ve got it done.

Oh wait, some teams use NPM and standardVer. Time to repeat the process.

Oh, and some teams use the semver package. Got it, one more time around the block.

But some teams use PNPM, etc. etc. the cycle goes on.

The scope is, practically, infinite.

We need the Golden Path to prevent overloading our Delivery Team with a unbounded scope of technologies to learn and understand. An unbounded scope of technologies that: all do the same thing.

So, what do these decisions translate to for the user?

For the everyday engineer, it becomes a simple flow of write code, and let automation do the rest.

We’ve taken all the cognitive load of deciding how to secure, test and deploy the code, so all that’s left to the engineer is to commit the code, see what the tools tell us about its mergeability, and make corrections if necessary.

We don’t have to worry about the decisions made, unless we want to.

Sign Off

At this point, I hope you understand more about what a Golden Path is and why you need to start thinking about one. It scopes the cognitive load for platform and product engineers alike, so that both can focus on doing what they’re good at: building.

Every day, we build our software standing atop the shoulders of giants, and I think it’s time we formalise that.