Skip to main content

Definition of “Cognitive Load”

We’ll start with an extract from https://en.wikipedia.org/wiki/Cognitive_load and our interpretation in a software product development context.

Cognitive Load Wikipedia

To fully understand how cognitive load manifests within software product development, we must consider three types of cognitive load:

  • Intrinsic Cognitive Load: The effort needed to change the software product.

  • Extraneous Cognitive Load: The effort needed to read and understand what to change in a software product.

  • Germane Cognitive Load: The effort needed to develop permanent knowledge, or, in other words, expertise.

Let’s explore the concept of extraneous cognitive load and how we can interpret it, as there might be a mismatch between our interpretation and yours.

Concerning extraneous cognitive load, there is a split between "instructor" and "learner," which might be misleading. In our experience within software product development, the learner is frequently the instructor for other learners, or even themself.

Looking at the above Wikipedia snippet, let’s look at the description of extraneous cognitive load: “Extraneous cognitive load refers to the way information or tasks are presented to a learner.” So, according to this, there are two possible factors at play:

  1. Presentation of information.

  2. Presentation of a task.

Let’s zoom in on “presentation of information.”

Unless you work as a solo entrepreneur or your organization consists of just one product engineer, the information created (in other words, the code created by you) will, at some point, become the information (or code) consumed by another product engineer in your organization. Plus, the code created will surely be consumed by you again sometime in the future. In that sense, within software product development, the learner is an instructor, and the instructor is a learner.

Learner is Instructor

Now, let’s move on and examine “presentation of a task.”

In traditional organizations, developers are isolated to delivery and maintenance activities and discovery activities are performed by others, which greatly influences extraneous cognitive load. In organizations where the same teams​​ handle both discovery and delivery, the tasks will be presented or created by the same teams. Again, in this case, the learner becomes the instructor, and vice versa. This will be discussed further in the remainder of this book.

For now, we mainly focus on the presentation of information or tasks in relation to extraneous cognitive load, paying less attention to the split of instructor and learner. Although we know that many product development groups still have an explicit organizational split between delivery and discovery people, we assume that you already understand the benefits of developers also being involved in discovery.

Next, let’s examine germane cognitive load, or the effort required to develop permanent knowledge within a software product development environment.

Within product development, we are innovating, either in small or large increments— each feature we develop within the product is an invention and something not done before, thus limiting the benefit of the permanent knowledge acquired earlier. We also need to maintain a growing amount of existing software, which is often not even built by the same people. On top of that, technology and markets are changing so rapidly that the value of permanent knowledge could even become a blocker for innovation, rather than a benefit. This is all related to the well-known S-curve pattern of innovation and how fast an organization chooses to engage in it. While domain knowledge might be more consistent than technology knowledge, both are fluid in nature, and the asset of permanent knowledge is time-bound (note the relevance of Ebbinghaus’s forgetting curve as described further on in this book).

Cognitive Load System Model The above figure is called a system model and part of a practice called system modeling. This practice encourages applying systems thinking when trying to understand the problems we experience more holistically. It encourages us to seek understanding of complex dynamics instead of simple but wrong answers to complex problems. We use systems thinking throughout the whole book.

In this particular system model, we observe that with increased or decreased number of features, and just general amount of software, developers will experience higher cognitive load. At the same time, the more we can apply existing knowledge, the lower this cognitive load will be regardless of the software size or number of features. This last part of the dynamic becomes especially important since our long-term knowledge grows with repetition. When we apply something only once, we tend to forget very quickly.

The last box about the amount of change in technology & markets shows the relationship with amount of existing applicable knowledge. The knowledge that quickly becomes outdated will negatively influence existing applicable knowledge. What does it mean in reality? For example, developers that prefer highly volatile trends and tools over more fundamental engineering practices and software patterns will suffer and complain more about being overwhelmed or cognitively overloaded. And much more importantly, each new developer in future will need to deal with this legacy of outdated implementations with deprecated technologies. Maintaining someone else's code who already left for another company, chasing another trend, is considered one of the worst things about being a developer. As you can imagine, we could explore this dynamic much deeper with many additional variables. Instead of creating one gigantic and fully connected system model, we explore parts of it. Although a single fully connected model is more holistic, it would likely cognitively overload you as a reader.

In summary, the above system model shows relationship and dynamic between certain types of knowledge, inevitable changes in technology/market and cognitive load.

In line with this, we can also explore the opposite direction and ask ourselves:

  • Could also knowing too much turn into a blocking factor for innovation and changing gears?

  • Why would one want to give up his or her expertise for something new and become a beginner all over again?

See “The law of the handicap of a head start” which elaborates on the fact that an early advantage can become a disadvantage over time. Being knowledgeable about a certain path taken can lead to complacency and resistance to change, while fresh minds (possibly competitors) are often more innovative and adaptable. See: https://en.wikipedia.org/wiki/Law_of_the_handicap_of_a_head_start

Myth: Cognitive load is about the amount of knowledge - There is a limit to the amount of knowledge a developer or team can have​

We often notice statements like this: “Teams are cognitively overloaded because they must know so much about components to properly maintain them.” In our experience too, many teams feel overwhelmed seemingly by number of components they need to maintain. However, merely looking at the number or size of components, we ignore so many more factors that also play significantly larger role in the feeling of being overwhelmed. We will explore those factors in the later chapters.

At the time of writing this book, Emily Nash, Canadian, is 18 years old and very unique. She has HSAM (highly superior autobiographical memory)—the incredible ability to remember almost every minute of every day in her life, as though it happened yesterday. There are only 62 known people in the world with HSAM. This condition has many advantages, as you can imagine, but also drawbacks, including the inability to forget bad experiences. Interestingly, even for people with such extreme ability to remember, there is no capacity problem, and scientists are researching how, even for them, the brain doesn’t become full. So, from this, we can understand that the human brain is not a hard drive, and we haven’t found a limit to its capacity. Also, the fact that we forget things has nothing to do with our supposed brain’s limited capacity to store information. In software development, the only limit is the time it takes to (re)learn—therefore, cognitive load has nothing to do with the amount of knowledge a person can possess.

Since there is no known limit to brain capacity, feeling of being overwhelmed cannot be caused by some imagined limit to the amount of knowledge one can acquire and retain. There is, of course, the effort required to gain that knowledge. How fast we can do that has limits (hence germane cognitive load).

In the subsequent chapters, we will support our reasoning by exploring the definitions of: