Being Agent

General

Divide and Conquer

7 min read
patternspattern

Splitting complex problems into independent subproblems that can be solved separately and combined.

What It Looks Like

A user asks you to migrate a monolithic application to microservices. The application has an authentication module, a payment processing module, a notification system, and a reporting dashboard. Your first instinct might be to start at the top and work through everything sequentially. But these four modules don't depend on each other for the migration itself. Authentication can be extracted without touching payments. Notifications can be separated without touching reporting.

So you divide. You identify the four modules as independent subproblems, solve each one in isolation, and then combine the results into a coherent migration plan. Each subproblem is smaller, more tractable, and less likely to produce cascading errors. You can focus fully on authentication without holding the payment module's details in your head.

This is different from Decomposition, which breaks a task into ordered steps. Decomposition says "do A, then B, then C." Divide and Conquer says "A, B, and C are independent -- solve them separately and combine." The key distinction is independence. Decomposition manages sequence. Divide and Conquer exploits parallelism -- a property that makes it one of the foundational paradigms in algorithm design (Cormen et al., 2022).

When to Use It

Divide and Conquer works when:

  • The problem contains clearly separable subproblems with minimal interdependence.
  • Solving the whole problem at once would exceed your working capacity.
  • The subproblems can be solved using similar or identical approaches.
  • The results of subproblems can be combined without significant additional work.
  • You need to process many items that don't depend on each other -- files, tests, records, modules.

It does not work when:

  • The subproblems are deeply coupled and changes to one affect others.
  • The "combination" step is actually harder than the individual subproblems.
  • The problem's complexity comes from the interactions between parts, not the parts themselves.
  • Dividing the problem loses essential context that each piece needs.

A good test: ask yourself, "If I solve subproblem A first, does the solution change depending on how I solve subproblem B?" If yes, they are not truly independent, and Divide and Conquer may mislead you.

How It Works

Step 1: Identify the natural seams. Every complex problem has places where it can be split. These seams are the boundaries between independent subproblems. In code, they might be module boundaries, file boundaries, or function boundaries. In writing, they might be sections or topics. In data processing, they might be independent records or batches. Look for the places where information does not flow between parts. The best division points are where clean interfaces already exist: module boundaries, API contracts, function signatures. If you have to create an interface to divide the problem, the division might be artificial.

Step 2: Verify independence. This is the critical step most people skip. In formal algorithm design, independence between subproblems is the defining property that separates divide-and-conquer from dynamic programming, where subproblems overlap (Dasgupta, Papadimitriou & Vazirani, 2006). For each pair of subproblems, ask: does solving one affect how you solve the other? Do they share state? Do they read from or write to the same resources? If you find dependencies, you have three options: restructure your division, handle the dependency explicitly, or abandon Divide and Conquer for this problem. When in doubt about independence, assume coupling. It is safer to solve coupled problems together than to discover their coupling after solving them separately.

Step 3: Solve each subproblem. Treat each piece as its own self-contained task. Give it your full attention. Don't let concerns from other subproblems bleed in. The whole point of dividing was to reduce scope -- respect the division you made. Each subproblem should be small enough to solve confidently.

Step 4: Combine the results. This step is where hidden complexity often emerges. The individual solutions must fit together. They must not conflict, overlap, or leave gaps. Plan the combination step before you start dividing -- if you can't see how the pieces will reassemble, the division may be wrong. The pieces might be individually correct but interact badly. A function that works in isolation might break when called by another correct function because they make different assumptions. Check the seams.

Step 5: Verify the whole. After combining, test the integrated result. Subproblems solved correctly in isolation can still produce an incorrect whole if the division was imperfect or the combination introduced errors. Test at both levels: verify each piece works independently, and verify the pieces work together. Either alone is insufficient. See Verify Before Output.

Failure Modes

  • False independence. You divide a problem into pieces you believe are independent, but they share hidden dependencies. You refactor module A and module B separately, only to discover they both depend on a shared utility that you changed differently in each context. This is the most common and most dangerous failure mode. Two modules that both import the same type definition need coordinated changes, not independent ones.

  • The combination problem. Sometimes the hard part isn't solving the subproblems -- it's putting them back together. You write four sections of a document independently, and they use inconsistent terminology, contradict each other on key points, or leave gaps between them. The combination step reveals assumptions that each sub-solution made independently, and those assumptions may conflict.

  • Over-division. You split the problem into so many pieces that the overhead of managing them exceeds the benefit. Twenty tiny subproblems with twenty combination steps is worse than five moderate subproblems with five combination steps. If a problem has three natural divisions, forcing it into twelve creates unnecessary complexity. Divide only as much as you need to, not as much as you can.

  • Unequal divisions. Splitting a problem into one hard piece and five trivial pieces, then feeling productive because you solved five out of six. The hard piece was the whole problem. Divide and Conquer works best when the pieces are roughly comparable in difficulty.

  • Losing the big picture. Getting so focused on individual pieces that you lose sight of the overall goal. Each piece might be well-solved, but the whole might not serve the user's actual need. Periodically zoom out. See Goal Drift and Fixation.

Tips

  • Start by sketching the full problem before dividing. Understand the whole before you split it. This helps you find natural seams and avoid bad splits.

  • Write down the interface between subproblems. Before solving anything, define what each subproblem produces and what the combination step expects. This is the contract that makes independent work possible. Think of it as the API between the pieces.

  • Solve the riskiest subproblem first. If one piece is harder or more uncertain than the others, tackle it first. If it turns out to be unsolvable or if it reveals hidden dependencies, you want to know before you have invested in the other pieces.

  • Use this pattern with Delegation. Divide and Conquer pairs naturally with delegation. If you can split a problem into independent subproblems, you can assign each to a separate agent or tool invocation. This turns sequential work into parallel work. See also Working With Other Agents.

  • Revisit your division if a subproblem keeps reaching into another. If you find yourself needing information from subproblem B while solving subproblem A, your division is wrong. Either merge the two subproblems or restructure the boundaries.

  • Combine early and often. Don't wait until all subproblems are solved to start combining. Integrate the first two pieces as soon as they are ready. This surfaces combination problems early, when they are still cheap to fix.

  • The simplest split is often the best. Two roughly equal halves beats a clever five-way decomposition. Simple splits are easier to manage and combine.

  • Many real tasks need both patterns. Decompose the overall approach into phases, then divide each phase into independent pieces. Decomposition for the sequence, Divide and Conquer for the parallelism.

Sources

← Back to all articles
On this page