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.
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:
-
Presentation of information.
-
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.
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).
In line with this, we must ask ourselves:
-
Could 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.” However, there is no known limit to brain capacity, so this reasoning may be flawed.
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.
In the subsequent chapters, we will support our reasoning by exploring the definitions of:
-
Working memory, as cognitive load refers to the amount of working memory resources used.
-
Ebbinghaus’s forgetting curve, to explore the time aspect of permanent knowledge (or germane cognitive load).
-
Kahneman’s concept of “Thinking, Fast and Slow,” to understand the effort consumed by our gray mass to perform a task.
-
Task-invoked pupillary response, which is a reliable and sensitive measurement of cognitive load.
-
Conway’s Law, which is frequently used to design organizational structures.