Complexity poses a primary obstacle for developers. Our human neurology has a limit to complexity wired into each of us. The basics of Clean Code techniques can ease understanding and productivity by decreasing what we must keep in our working memory.

One of the most highly cited papers in psychology, “The Magical Number Seven, Plus or Minus Two: Some limits on Our Capacity for Processing Information” was published in 1956. This paper reports 7 +/- 2 as the number of objects the average human can hold in working memory. This correlates to about three bits of information: 2**3 = 8 as a maximum performance level of the average human.

Miller’s experiments have been replicated many times and in many different contexts. The results are generally consistent with the above findings of 7 +/- 2. A highly cited paper becomes a source of experimentation to either prove or disprove the premise of that paper. While Miller’s paper has certainly had it’s original premise examined and extended, the paper has been found quite solid. Thus the moniker, “Miller’s Law”.

Applications to Software Craftsmanship

In a practical context, Miller’s law demonstrates our inability to easily remember too many “things” at one time. Our application of software development can use Miller’s observations to aid in our Clean Code Craftsmanship.

Miller’s Law can explain the reasons behind our confusion of certain code because the complexity swamps our cognitive abilities to understand. We certainly do not say a developer is too stupid to understand, but we do say that code complexity easily overwhelms understanding.

We have all struggled with understanding certain pieces of code. We tried to find that “just right” place to fix that bug or add that new feature. We tried to understand it well enough to add a proper unit test. Remember that feeling of frustration?

Unfamiliar structures or routines results in struggling that code. As more and more of these struggles pile on, our understanding of the code decreases because we can easily lose track of the finer details. This leads us to the next component: Working Memory

The Fallacy of Multitasking

Some people tell me they are very good at multitasking. All evidence proves otherwise. Let’s say you’re working on a coding activity, and suddenly you’re trying to multitask another activity, like talking to a coworker. You are not actually doing both at the same time. You are diverting attention from one part of you brain to another. That takes time and resources away from each activity.

The conversation task starts a new activity so you’re somewhat slower in forming proper attention. That coding activity might have pieces dropping out. And the longer the conversation, the more pieces drop out.

Most people can shift focus really fast, somewhere about 1/10th second. That fast context switch time doesn’t matter as much as the bandwidth the brain requires to move back and forth. Your overall performance and quality get impacted.

While multitasking often gets described as fun, the people who claim they multitask very well have been proven almost always among the worst. Absolutely no studies have proved that multitasking improves final outcomes.

Dave Crenshaw says in his book that The Myth of Multitasking. No one can really multitask. No positive effects of multitasking exist. Dave even includes a multitasking test that demonstrates this principle: Think you’re good at multitasking? Take this test. Some have gone so far at to state that multitasking is worse than smoking pot.

Negative effects of multitasking include:

• The task takes longer to complete.
• Chances for mistakes increase.
• Stress levels increase.
• Relationships suffer.

Clean Code suggests that concentrating on one and only one task optimizes performance. Why? Because it keeps our working memory cache at a low number. We can concentrate on things that matter to our task. We can ignore the irrelevant. Distractions only encourage our working memory to dump its cache and context switch to distracting influences.

Peopleware

“Peopleware” discusses team productivity issues. One section discusses their attempts to discover what makes a good team. They attempted and failed. What they did find was how to destroy a team’s productivity. Imposing multitasking by interruptions, endless meetings, bad environments, pointless distractions, impossible schedules, etc. significantly weighed in the negative.

From emphasizing the importance of providing a workplace environment conducive to creative development to challenging the most common project management delusions, the authors make a compelling case on why a lot of managers approach software development in the most detrimental manner possible. Peopleware uses the term “teamicide”.

These varieties of multitasking do not assist a team in achievement of goals.

In The “Flow”

In positive psychology, “flow”, also known as “zone”, describes a mental state in which a person performing an activity becomes fully immersed in a feeling of energized focus, full involvement and enjoyment in the process.

That person enjoys complete absorption in that activity.

This concept has been widely referenced across a variety of fields. Flow is completely focused motivation, a single minded immersion and represents the ultimate experience in the service of performing. Whatever emotions are present are not just contained, but positively energized and aligned with the task at hand. The hallmark of flow is a feeling of spontaneous joy, even rapture while performing the task.

Personally, I love developing “in the flow”. When I experience this state I can program for several hours knowing my resulting code exhibits a high quality. My other needs become negligible. My surroundings vanish. The general office clatter disappears. My gratification remains at a high level.

I feel this state strongly resembles a meditative state – an optimal experience. I get lost in my work and time seems to almost disappear.

How can flow in the workplace be achieved? Would flow result in satisfactory outcomes for all? Better software? Happier people? Higher morale? Increased group rapport? Higher collaboration?

Good Business: Leadership, Flow, and the Making of Meaning addresses the creation of flow at work. Although many people view the workplace negatively, getting “in the flow” at work should be goal of managers.

Some people suggest that the “flow” creates detrimental conditions for good code. These problems include too tight focus, too fragile a state, isolation of individuals does not spread knowledge, long feedback loops and others. The suggested alternative to the zone is pair programming.

Reality is Broken: Why Games Make Us Better and How They Can Change the World points out that people immerse themselves in games, i.e., get “in the flow” in games. People become incredibly addicted to their games for no substantial worldly rewards: points, badges, etc. These rewards exist only in the minds of the players, they are certainly not real!

How can we create a workplace containing these gaming aspects?

Open Plan Offices?

As a developer, I need time and space to concentrate. Yes, sometimes I need to discuss with others about various issues involved with our project. But, so many times someone near begins a loud conversation, a meeting nearby disbands with a flurry of noise and comments in the hall, someone near talks loudly on their phone, someone interrupts me for no particular reason than they want to talk, a group of people move about in my visual field, etc. How can open plan offices be the plan of choice for developers? I find open plan offices incredibly irritating. I want to get “into the zone” and stay there for a substantial portion of my coding.

The most creative people in the world are introverts, according to psychologists Mihaly Csikszentmihalyi and Gregory Feist, because they’re able to concentrate on the task at hand.

Some advocates of open plan offices insist the increase in collaboration is well worth any demerits. I ask, “How do you measure collaboration?” So far, no one has offered a metric for this measurement.

Read more: Why an Open Office Environment Can Totally Kill Creativity.

Working Memory: Cognitive Overload at about Four

“Working Memory”: Our human system responsible for the transient holding and processing of new and stored information. This working memory may consist of small bits of information or large chunks.

Working memory can also represent our ability to keep multiple things in mind at the same time.

Working memory generally consumes our attention span. Shifting our attention span flushes our working memory cache. This explains the reason interruptions result in disruptions of work. Working memory consumes a significant portion of our 7 +/- 2 limitations.

Experiments have show that the average person under normal conditions uses about four items of information to operate in everyday life. Experiments have proved this over and over. This does not mean that the 7 +/- 2 rule does not hold! People can use their attention spans to hold more information. As developers we do this all the time.

A surprising limitation indeed: working memory can hold only about 4 things at once.

Working memory plays a major role in our everyday life. Whether reading a blog, planning dinner, or making a complex decision, we must store information from each of the intermediate steps. Many, many questions can arise from these interactions. And yet, each of us usually succeeds in handling these life situations. Imagine that – we commonly live in a life with only about four items at once!

I suggest that working all day with 7 +/- 2 items of information all day long can be tiring. And when working on difficult code, the memory overload of even more than the magical 7 can be even more tiring. All that “up-time” consumes a lot of energy.

I further suggest that if we coded with the working memory capacity of four as a goal, our code could be more maintainable, understandable – “clean code”.

…And Your Tools

Speaking of working memory… perhaps you have ignored mastering the tools you work with each day? Your editors, debuggers, build, continuous integration, emailers, source code control system, etc. all take effort to use intelligently.

How well do you really know that editor you work with all day long? I assume you use eclipse, vim, emacs or similar programmer’s editor. If not, what are you doing programming? I have interviewed people who state they use notepad for coding java! (They weren’t too sharp in other areas as well.)

You must know your editor well enough that thinking about an editing task does not even occur – it just happens. Your fingers do the walking. Specifically, your working memory is not even involved. No overload happens at all because you don’t have to think about that editor – it just happens.

The same reasoning applies to all you other development tools. You should master each so well that performing everyday tasks does not burden your working memory.

With node.js/javascript this can present challenges. The well advertised messiness of this language demands an even greater effort to master with all its foibles and quirks. Perhaps you don’t use the bad parts, but you’ll certainly encounter them in your daily work. Add in the required understandings of callbacks and working memory capacity can easily cause mental stack overflow!

…And Your Life

The above discussion implies that your life, and mine, get experienced at about four chunks at a time. As our life progresses, that is all the information we use as we stroll down that path we call life. Can that really be true? Four chunks at a time?

Have you ever discussed a significant childhood event with someone in your family? Noticed the major difference of the memory of that event? Perhaps you were paying attention to one aspect while your family member was paying attention to another?

The very phrase “paying attention” implies our attention somehow gets constricted, diverged or otherwise contracted. The “paying” part implies we lose something – when we pay money we lose it. When we “pay attention”, who do we pay? What do we lose?

Working Memory and Clean Code

What would happen if we planned to develop code within our working memory capacity of about four? That is, only hesitantly use more than four items of information at a time? What barriers would present themselves? What types of problems arise from overloading our working memory capacity? How could we integrate the limit of four with our development process?

The following paragraphs provide representative applications of working memory to coding.

Good Names

Humans are good at words.

A clearly expressed concept in software with a good name eases understanding of the concept. We commonly make an analogy to something we already know. “A class is a container of data and methods.” Since we understand what data and methods represent, a class becomes easier to understand.

When we encounter something without a linkage to our current conceptual vision, we may have difficulties. When first starting computer science studies, concepts such as “module” and “methods” were somewhat fuzzy. It took a while to embrace “methods” as something slightly distinct from “functions”.

Most of us find learning foreign languages difficult. These statements are not, of course, contradictory. A good word describing a concept provides a solid visual anchor. Remembering that same word in a foreign language creates a problem because we can’t usually find a good way to anchor that foreign word.

SOLID Principle – Single Responsibility Principle

The Single Responsibility Principle, SRP, states that a class should have one and only one responsibility. A class has responsibility over a single part of the functionality of the software system and all that responsibility should be entirely encapsulated by the class.

In terms of working memory capacity, notice that only one class needs a presence in working memory to understand its functionality.

As a counter-example, consider a class that calculates and prints a report. This class has two responsibilities. For long-term maintenance a developer must remember both responsibilities to properly maintain this class. A developer may also wonder if changing the calculations will change the printing of the report and vica versa. As for dependency management issues, how does a developer untangle these dependencies?

Violations of SRP usually manifest in large classes or large methods.

In terms of working memory capacity, imagine if every class and method contained SRP violations. How clearly could names communicate the true purpose of the class? With what ease could we retain all these variations containing mixed-up logic? How could we reason about potential problems in these classes?

Violations of the other SOLID principles similarly pose working memory capacity issues.

Clean Code Overall

A basic goal of Clean Code involves minimizing working memory capacity requirements. This does not imply a developer cannot develop and understand complex systems. Skilled developers with Clean Code skills minimizing working memory capacity can find their productivity increasing. Indeed, many skilled developers will find they already use techniques that lower working memory requirements.

Links

A large body of material exists for this phenomenon of 7 +/- 2. Google “magic number 7”, “working memory”, “memory overload”, “cognitive overload”, etc. Education sites have a lot to say about this concept.

Ted Talk: How your working memory makes sense of the world”.

If you think that a limited working memory is a liability: Confessions of a Limited Working Memory Victim, think again! Physicists, mathematicians and engineers commonly have this limitation! (strange..)

Peopleware: Productive Projects and Teams provides an essential reference on team building and their environments. I found it interesting that they attempted to find what makes a great team, then gave up and instead discuss how to destroy a team.