Decomposition
Big Problems Are Just Bundles of Small Ones
Decomposition means breaking a large, complicated problem into smaller, more manageable parts β then solving each part separately.
It is the first tool of computational thinking, and you already use it: you do not "do homework", you do the math worksheet, then the reading, then the science questions.
Why Decompose?
| Advantage | Why it matters |
|---|---|
| Easier to understand | A small problem fits in your head; a huge one does not |
| Easier to solve | Each part needs a simpler algorithm |
| Easier to test | You can check each part works on its own before combining them |
| Easier to share | Different people can work on different parts at the same time |
| Easier to reuse | A solved part (like "sort a list") can be reused in other problems |
Worked Example β Plan a Class Party
"Plan a class party" is too big to act on. Decompose it:
Plan a class party
β
ββββββββββββββ¬βββββββββ΄ββββββββ¬ββββββββββββββ
β β β β
Food Music Decorations Invitations
β
βββββ΄βββββ
β β
Snacks Drinks
Now every leaf of the diagram is a task someone can actually do. Notice that Food was still too big, so it was decomposed again β decomposition can be repeated until every part is simple.
Decomposition in Software
Every app you use was built this way. A video game decomposes into:
- Graphics β drawing characters and backgrounds
- Input β reading the controller or keyboard
- Game logic β rules, scoring, winning and losing
- Sound β music and effects
Each part is designed, built, and tested separately, then combined. One programmer might spend all week on just the scoring β and never touch the graphics.
How to Decompose a Problem
- Write the big problem at the top
- Ask: "What separate jobs make this up?"
- List the parts β aim for parts that do not overlap
- Check each part: is it small enough to solve or explain easily?
- If not, decompose that part again
- Solve the parts, then combine them into a full solution
A good test: could you hand each part to a different classmate with a one-sentence instruction? If yes, your decomposition is clear.
Combining With Other Skills
Decomposition rarely works alone. After breaking a problem apart, you will often use pattern recognition to spot parts that are similar, and abstraction to ignore details that do not matter. Together these skills turn scary problems into checklists.
Worked Example β Building a Quiz App
"Build a quiz app" looks like one enormous task. Decompose it properly and it stops being frightening:
Build a quiz app
β
ββββββββββββββββ¬ββββββββββ΄ββββββββββ¬βββββββββββββββ
β β β β
Question bank Scoring User interface Results screen
β β
βββββ΄βββββ βββββββββββ΄ββββββββββ
β β β β
Store Pick a random Show a question Show buttons
questions question and choices for answers
Look closely at what happened to "User interface" β it was still too big on its own, so it was decomposed again into "show a question" and "show buttons", exactly the repeatable process from the steps above. Now compare the leaves of this diagram with things you already know how to build: "pick a random question" is a small algorithm using a list; "show buttons for answers" is an input problem; "scoring" is a variable that goes up when an answer matches. A task that felt impossible on Monday morning becomes five familiar, separately solvable jobs by Monday lunchtime.
When Decomposition Goes Wrong
Two mistakes are common enough to name directly. Splitting too unevenly β decomposing "make dinner" into "chop one carrot" and "cook everything else" gives two parts, but they are wildly different sizes, and the second one still needs decomposing. Good decomposition aims for parts that are roughly comparable in size and complexity, not just any split. Splitting along the wrong lines β a bad decomposition of the quiz app might separate "code for question 1" from "code for question 2" from "code for question 3", duplicating the same structure three times instead of noticing (via pattern recognition) that all three are the same job repeated. Recognising which cut through a problem produces genuinely independent, reusable parts β rather than just any cut at all β is the skill that improves with practice.
Key Words
- Decomposition β breaking a problem into smaller sub-problems
- Sub-problem β one of the smaller parts produced by decomposition
- Computational thinking β solving problems the way a computer scientist does: decompose, spot patterns, abstract, then design algorithms