Decomposition

⏱ 7 min✏️ Quiz at the end

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?

AdvantageWhy it matters
Easier to understandA small problem fits in your head; a huge one does not
Easier to solveEach part needs a simpler algorithm
Easier to testYou can check each part works on its own before combining them
Easier to shareDifferent people can work on different parts at the same time
Easier to reuseA 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

  1. Write the big problem at the top
  2. Ask: "What separate jobs make this up?"
  3. List the parts β€” aim for parts that do not overlap
  4. Check each part: is it small enough to solve or explain easily?
  5. If not, decompose that part again
  6. 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