Measuring Cognitive Load as a software engineering team
Cognitive Load is a concept popularised by John Sweller (see Cognitive Load During Problem Solving: Effects on Learning).
In a previous article, I examined Sweller’s theories about “forward-working strategies”. This is part of Sweller’s analysis which leads to categorisation of different types of load.
However, I also note that his characterisation of working strategies isn’t well suited to how we work as software engineers. His theories about Cognitive Load are thus hard to validate within our context.
In particular, the distinction of “germane” from “extraneous” is problematic when dealing with, for example, understanding a codebase. The distinction of code from its environment is by no means black-and-white. The same can be said for “infrastructure” in general.
Nevertheless, industry experts such as Skelton and Pais (Team Topologies, 2019) state that Cognitive Load is a problem for teams. Seasoned software engineers also learn to avoid unnecessary complicatedness via heuristics such as:
- “avoid premature optimisation”
- “KISS”
- “over engineering”
There is consensus that we need to set our brains up for success when working with software.
As part of continuous learning, it’s worth monitoring how context-switching is affecting a team. As part of regular retrospective analysis, it’s worth doing a quick temperature check to validate team health in this area.
Below is a picture of a simple spreadsheet. This is an example of how you could do this in a rudimentary fashion. Note that each team needs to customise metrics to suit its own context, and commit to a version which works for them (ideally for at least six months at a time.)
I recommend using this in a similar fashion to the Kanban heuristic of limiting WIP (Work-in-progress). The team sets a limit beyond which they will no longer take on additional work if it involves switching to a new context. This forces us to plan ahead about which contexts we will focus on within the next iteration.
