Decomposition
Decomposition is the act of breaking a problem you cannot solve into parts you can. It is the first pillar of computational thinking for a reason: every other technique — pattern recognition, abstraction, algorithm design — operates on the pieces that decomposition produces. Decompose badly and no amount of clever downstream work will save you.
Why decomposition works
Human working memory holds a handful of items at once. A problem with fifty interacting concerns is cognitively unsolvable as a whole; the same problem split into seven clusters of seven is merely tedious. Decomposition converts an impossibility into a schedule.
It also enables three things wholes cannot offer:
- Parallelism. Independent parts can be solved by different people, teams, or AI agents simultaneously.
- Testability. You can verify a part in isolation long before the whole exists.
- Replaceability. When requirements change, you swap one part instead of restarting.
The quality test for any decomposition is coupling and cohesion: each part should make sense on its own (high cohesion) and depend on other parts as little and as explicitly as possible (low coupling). A decomposition whose parts constantly reach into each other’s internals is a diagram, not a decomposition.
Three decomposition techniques
Different problems fracture along different lines. Skilled practitioners consciously choose the axis of the cut.
1. Functional decomposition
Split by what has to be done — verbs. A payroll run decomposes into: collect timesheets, apply pay rules, compute deductions, generate payslips, transfer funds. This is the most intuitive technique and maps directly onto functions, services, and checklist steps.
Best when: the process is well understood and roughly sequential. Watch out for: hidden shared state. If two “independent” functions both quietly edit the same record, your decomposition is fictional.
2. Data-flow decomposition
Split by how information transforms — follow the data, not the actions. Ask: what enters the system, what leaves, and what intermediate representations exist in between? Each transformation between representations becomes a component. This is the natural decomposition for pipelines, ETL systems, compilers, and ML workflows.
Best when: the problem is fundamentally about converting one form of information into another. Watch out for: transformations with side effects, which break the clean pipeline picture.
3. Stakeholder decomposition
Split by who cares about what. A school timetabling problem looks monolithic until you separate concerns by stakeholder: students need feasible course combinations, teachers need contract-compliant loads, facilities need room capacity respected, administrators need auditability. Each stakeholder concern becomes a constraint set or module with its own owner and its own definition of success.
Best when: the problem is socio-technical — most real problems are. Watch out for: conflicting stakeholder requirements. Surfacing the conflict early is a feature, not a bug: it is far cheaper to negotiate priorities before building than after.
Worked example: reducing customer churn
Problem statement: “Our subscription service loses too many customers. Fix churn.”
As stated, this is unsolvable — it names a symptom, not a problem. Decompose it:
Decompose by data flow
What would we need to know to act? Raw events (logins, support tickets, payments) → cleaned usage history per customer → churn-risk score → intervention decision → outcome record. Five representations, four transformations — each is now a separately buildable, separately testable component.
Decompose the risk question functionally
The “churn-risk score” box splits into: define churn precisely (no payment for 60 days? explicit cancel?), choose a prediction window, select signals, build a scoring rule, validate against past cohorts. Note that defining churn turned out to be a task at all — decomposition routinely exposes work that was invisible in the monolithic statement.
Decompose interventions by stakeholder
Retention offers involve finance (discount budget), support (outreach capacity), product (fixing the friction that drives cancellations), and legal (contact consent rules). Each gets an explicit interface: finance sets a per-customer offer cap; support sets a weekly contact quota. Conflicts — product wants root-cause fixes, marketing wants discounts — are now visible and negotiable.
Reassemble and check coupling
The final map: an analytics pipeline feeding a scoring service feeding an intervention queue, with three stakeholder-owned policy inputs. Any piece can be built, tested, or replaced alone. The original vague demand has become eleven tractable tasks with owners.
The punchline: nobody has written any code yet, and the hardest thinking is already done. That is decomposition doing its job.
Common failure modes
- Decomposing by org chart instead of by problem. Conway’s Law will do this to you silently; do it deliberately or not at all.
- Stopping too early. If a part still feels overwhelming, it is not yet a part — recurse.
- Stopping too late. Forty micro-pieces with tangled dependencies are worse than eight clean ones. Decomposition has a cost; pay it only where it buys independence.
- Freezing the decomposition. Your first cut is a hypothesis. When evaluation (see Evaluation & Debugging) keeps failing at the same seam, the seam is wrong — recut.
In the AI era, decomposition is the skill that determines whether you can delegate work to agents at all: an LLM can execute a well-scoped subtask brilliantly and a vague monolith not at all. That thread continues in Problem Formulation.