Removing the Cost of Context Switching

In software design, there are two types of complexities: essential and accidental. Essential complexity represents the fundamental nature of a problem. There is no way to get around or reduce this complexity as it is born of the problem itself. Accidental complexity, on the other hand, is self-imposed. It is the complexity that we unnecessarily add to the software through inexperience, insufficient planning, technical limitation, and "résumé-driven development".

When working within the confines of the waterfall methodology, the scope of the project often becomes part of the project's essential complexity. Since every aspect of a waterfall project must be developed, tested, revised, tweaked, polished, and approved before it can be deployed, product engineers are forced to hold a tremendous amount of information in their head at all times.

This complexity of scope doesn't have to become "essential". However, when engineers don't have the technological means to safely and incrementally deploy work (via feature flags), the scope of the project takes on a de facto gravity that gives it an essential expression within the overall complexity.

This is why engineers always complain about being interrupted: they are holding the entire world of a project in their heads. When they stop working in order to assist a fellow engineer or to explain something to management, this mental model disappears—poof—just like that! Which means, when returning to their own work, each engineer must rebuild that entire mental model before they can continue on with their coding.

Some engineers claim that this rebuilding process can take up to 30 minutes. Which is why, if they have a meeting coming up in 15 minutes, they may not even bother going back to work as they know that such efforts will be a waste of time (and that the rebuilding process will have to start again after the meeting concludes).

One analogy that may help illustrate the nature of this complexity is the Fibonacci sequence. The Fibonacci sequence is a sequence of numbers in which each number is the sum of the two preceding values in the sequence. This means that any entry (n) in the sequence can be described as:

F(n) = F(n-1) + F(n-2)

... where F(0) and F(1) are constants.

Each individual calculation is actually quite simple—the addition of two numbers. Any child with a rudimentary understanding of maths could grind it out if given the two preceding values. But, the essential complexity of the Fibonacci sequence stems from the scope of the work, not the individual calculations.

Calculating the 20th value in the sequence—F(20)—isn't just a matter of adding two values, it's a matter of first calculating F(19) and F(18). Which is a matter of calculating F(17) and F(16). Which is a matter of calculating F(15) and F(14). And so on, all the way down to F(2).

Having to develop projects using traditional methodologies is akin to calculating and retaining the entire Fibonacci sequence in your head. Which means, if you're working on the analogous F(20) step of your project when someone interrupts you, you don't get to start back at F(20) when returning to your work. Instead, you have to start back at F(2) and recalculate entries—one entry at a time—until you get back to F(20).

Such is the overhead of maintaining a large mental model when working on a long-running project. It is why the scope of work becomes part of the essential complexity. And, it is why the cost of context switching is so high for so many engineers.

But, it doesn't have to be this way. When using feature flags to build a product, we can greatly reduce the cost of context switching. It might never be nothing; but, it will certainly be low enough to remove the friction of interruptions.

As discussed in the life-cycle chapter (see Life-Cycle of a Feature Flag), thinking in feature flags requires the engineer to take a large project and break it up into many small tickets. Each of these tickets is then implemented and deployed to production in turn.

Treating each ticket as a separate deployment does something magical: it forces the engineer to think deeply about the order of operations; and, how to draw boundaries around small, cohesive pieces of functionality that incrementally drive the product forward.

Technically, the same mentality can be applied in a traditionally-managed project. But, there's something about the deployment constraint itself that reorients the engineer. It narrows the engineer's field-of-view; and, forces them to think about the work as a collection of sequential steps that each act to unblock the next piece of functionality.

Going back to our Fibonacci analogy, each calculation within the sequence would be articulated as a separate ticket. And, each calculation would then be implemented and deployed to production in turn:

• Implement F(2).
• Deploy F(2) to production.
• Implement F(3).
• Deploy F(3) to production.
• Implement F(4).
• Deploy F(4) to production.
• Implement F(5).
• Deploy F(5) to production.
• ... an so on ...

Now, instead of having to hold the entire Fibonacci sequence in ones head, each intermediary value is codified in the application code, allowing each subsequent calculation to build on top of the previously calculated values. This takes what is normally a complicated, recursive algorithm and transforms it into a series of very simple calculations.

At this point, there is no cost to context switching. If you get interrupted while working on F(20) (in this analogy), you don't have to start back at F(2); F(n-1) and F(n-2) have already been calculated and integrated into the application workflow. As such, when you return to your context of work, there's no real mental model to rebuild—you just pick up where you left off.

Obviously, there's a big difference between doing math and fleshing out a robust, user-facing product. But, I'm hoping that the analogy helps to illustrate the way in which deploying a product incrementally with feature flags changes the overall project calculus. Instead of having to hold the entire project in your head, all you ever have to do is internalize the scope of a single ticket; and, trust that the project plan will lead you to success.

Not ever ticket is going to be super simple. And, certainly your first ticket—the one in which you atomize the work and devise a plan—will require deep thinking. Getting interrupted during these more sophisticated tickets does incur a higher cost of context switching. But, by decomposing the problem into sequential steps, you quarantine this type of work which significantly reduces the overall impact of interruptions.

Of course, all of this depends on coming up with a good plan; and, properly decomposing the work into small, digestible problems. This is a skill in and of itself; and, will take time to develop when you first start using feature flags. Do not be discouraged if there is an adjustment period.

When considering your plan of attack, I recommend that you focus on demonstrating value as soon as possible. By that, I mean prioritizing the work that puts something on the screen, even if it's not functional. If you recall from the life-cycle chapter (see Life-Cycle of a Feature Flag), the very first ticket we implemented—after adding the feature flag—was, "Add link, route, and placeholder view." The placeholder view didn't do anything, per se; but, it demonstrated value and gave us something to build upon.

This approach is not arbitrary—prioritizing visual work has a meaningful impact on the project. First, there are psychological benefits. When you can see something on the screen, it feels uniquely rewarding. This is doubly true when you share your work with others since a public demonstration of value speaks directly to one's ego.

This sense of reward keeps us energized. Which, in turn, motivates us to keep building and demonstrating value. Which, in turn, creates an internal fly-wheel of productivity.

Putting something on the screen also frees-up our mental resources. Unlike back-end work, which is far more abstract, getting ideas out of our head and onto the screen means that we no longer have to hold them within our mental model. This reduces the size of our working mental model; which, in turn, greatly reduces the cost of context switching.

Aside: The power of writing things down is the corner-stone of David Allen's book, Getting Things Done. I'm arguing that visual work, in product development, acts as a parallel to writing things down.

Prioritizing the visual aspects of work also helps us maintain a "just enough" mindset. Meaning, we build just enough back-end work to unblock front-end work and demonstrate value.

If you recall from the life-cycle chapter, each back-end ticket was followed by a, "Flesh out UI", ticket. We didn't build the entire back-end in one go; and, we didn't build the entire front-end in one go. At ever step, we did just enough to unblock something small-but-meaningful on the front-end. This encourages the creation of narrowly-scoped tickets; which, in turn, greatly reduces the cost of context switching.

And, of course, by focusing on the user-facing parts of a product, it keeps the user experience in the forefront of our development efforts. This serves to remind us that software is for the people; and, that it's built to solve a problem—not to pad one's resume with cutting-edge technology. This helps to eliminate noise and accidental complexity in the product; which, in turn, greatly reduces the cost of context switching.

We may never eliminate the cost of context switching. But, by working small and isolating the parts of a project that require higher cognitive load, we greatly reduce the overall impact of context switching. With time and practice, you'll find that—on balance—most of your project tickets incurs no switching cost at all.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4562