#40 - Context in Software Design
How Managing Information Improves Decisions and Reduces Complexity
Intro
A (vegan) customer walks into a restaurant (why are stories always about food?), reads the menu, and orders a salad (the "Mediterranean Garden Delight"). The cook prepares the meal, and the waiter serves it. However, the customer receives a not-so-vegan salad dressing. What went wrong?
I strongly believe in context—the more context you have (ideally in one place), the better decisions you can make. Let’s revisit the restaurant story with this in mind:
Before entering, the customer knew the restaurant’s name, location, and perhaps some reviews.
After entering, they saw the menu and maybe a dish or two nearby.
The waiter knew what the customer ordered but didn’t ask about dietary restrictions.
The cook only knew which meal to prepare and for which table.
Had the waiter asked about dietary restrictions, or if the menu clearly listed allergens, or if the customer had provided this info earlier, the experience would have been much smoother.
That said, context comes at a cost—asking for more information can slow things down, reduce conversions, and cause fatigue.
Now, let’s look at how context works in software design and share some tips for managing it.
Context
Context refers to the circumstances that form the setting for an event, statement, or idea, allowing it to be fully understood.
Here are some technical examples of context:
Frontend application context
AI LLM context
Microservices bounded context
Let’s dive into each.
Frontend Context Can Change
Frontend apps have context, often called state. For example, when I log into a gaming site, the context might include my username, recently played games and scores.
In our restaurant example, the frontend is the menu. The menu was printed last week, so it may not reflect what’s actually available (e.g., the waiter might inform you of unavailable dishes).
Similarly, changing the web application context and managing state updates are crucial. We’ll touch on this more later.
Varied Context Types
In LLMs (like Claude or GPT), the context window is the maximum number of tokens (characters) that can be processed. The context can include text, files, or media. Some context is required (like the prompt), while others are optional (like the temperature setting).
In our restaurant, there's a limit to how much you can order (you likely can’t order 1,000 meals) and optional parameters (you can request a meal change, but it’s not mandatory).
Bounded Context to Simplify
In microservices, particularly in domain-driven design, bounded context allows each service to manage its own terms. For instance, a “Campaign” in the acquisition service refers to paid ads, while in the game service, it refers to a character’s journey.
Similarly, the customer uses "Order" to mean the dishes they’ve chosen, while the cook uses "Order" to refer to missing ingredients. Setting the context makes communication more evident.
Tips
To make better decisions and reduce cognitive load, use these tips for managing context:
Set the stage: Define the bounded context—what domain are we in, and what are the key terms?
Just enough: Provide enough context, but keep it concise. Explain why something matters and offer examples.
Multi-modal: Context isn’t just text. Use visuals, documents, and verbal explanations to clarify.
Stay updated: Context changes. Keep everyone updated and make sure changes are communicated clearly.
Let’s look at an example of building a budget for the new year.
Stage: The manager shares the goal, boundaries (which budget areas we’re discussing), and standard terms (budget, cap, Opex, ROI).
Context window: Provide access to past budget sessions, a shared file, a timeline, and FAQs.
Variety: Use visuals, spreadsheets, office hours, and recordings.
Updates: Send weekly emails and ensure everyone has the latest version with updates.
Though context has a cost, providing the proper context at the right time usually pays off.