Breaking Problems Down

Decomposition is the act of taking a large, complex problem and splitting it into smaller, more manageable parts. It is the first step in nearly every successful problem-solving process because big problems are paralyzing and small problems are solvable.

What Decomposition Is

Decomposition means dividing a problem into subproblems that are easier to understand, solve, and manage individually. The key insight is that most complex problems are not actually one problem. They are a collection of smaller problems tangled together, and progress comes from untangling them.

Think of it this way: nobody builds a house all at once. You lay a foundation, frame the walls, run the plumbing, wire the electricity, install the roof, and finish the interior. Each of those is a distinct problem with its own skills, tools, and sequence. Trying to do them simultaneously would be chaos.

Why It Is the First Step

Decomposition usually comes before the other pillars of computational thinking because you cannot recognize patterns, abstract details, or design algorithms until you understand the parts you are working with.

When you face a complex problem and feel overwhelmed, that feeling is almost always a signal that you need to decompose. The overwhelm comes from trying to hold the entire problem in your head at once. Decomposition lets you put pieces down and focus on one at a time.

Before decomposition:
  "I need to plan a wedding."
  [Overwhelming, no clear starting point]

After decomposition:
  "I need to handle these separate parts:"
  - Venue selection
  - Guest list and invitations
  - Catering and menu
  - Photography and videography
  - Music and entertainment
  - Attire (bride, groom, wedding party)
  - Flowers and decorations
  - Transportation and logistics
  - Schedule and timeline
  - Budget tracking

  [Each part is a solvable problem]

How to Identify Subproblems

Identifying good subproblems is a skill that improves with practice. Here are reliable approaches.

Ask "What Are the Parts?"

Most complex things are made of parts. A business has departments. A meal has courses. A trip has legs. A project has phases. Start by listing the natural divisions.

Ask "What Needs to Happen First?"

Some subproblems have dependencies. You cannot send invitations until you have a venue and date. You cannot build the second floor until the first floor is done. Identifying what depends on what reveals the natural subproblems and their order.

Ask "Who Could Handle This Independently?"

If you could hand off a piece of the problem to someone else and they could work on it without needing constant input from you, that piece is a well-defined subproblem.

Ask "What Are the Different Types of Work?"

A problem often combines different kinds of work: creative work, logistical work, financial work, communication work. Each type can usually be separated into its own subproblem.

Identifying subproblems: Opening a small bakery

"What are the parts?"
  - Physical space (location, lease, renovation)
  - Menu (recipes, pricing, suppliers)
  - Legal (permits, licenses, insurance)
  - Financial (funding, accounting, pricing)
  - Staffing (hiring, training, scheduling)
  - Marketing (brand, signage, social media, website)

"What needs to happen first?"
  - Funding before lease signing
  - Lease before renovation
  - Permits before opening
  - Recipes finalized before supplier contracts
  - Hiring before training

"Who could handle this independently?"
  - A lawyer handles permits and licenses
  - An accountant handles financial setup
  - A designer handles branding and signage
  - A contractor handles renovation

"What are the different types of work?"
  - Creative: menu development, branding
  - Financial: budgeting, pricing, funding
  - Legal: permits, contracts, insurance
  - Operational: hiring, training, supplier relationships

Everyday Examples

Planning a Family Vacation

A family vacation is a single goal (have a great trip) that decomposes into many independent subproblems.

Family vacation to another country:

  Transportation:
    - Flights (research, book, seat selection)
    - Airport transfers
    - Local transportation (rental car vs public transit)

  Accommodation:
    - Research neighborhoods
    - Compare hotels vs rentals
    - Book and confirm

  Activities:
    - Must-see attractions
    - Day trips
    - Restaurants to try
    - Free/unplanned time

  Logistics:
    - Passports and visas
    - Travel insurance
    - Currency exchange
    - Phone/data plan
    - Packing

  Budget:
    - Total budget
    - Allocation per category
    - Emergency fund

Each of these can be worked on by different family members, at different times, in parallel. That is the power of good decomposition: it enables parallel work.

Organizing a Fundraising Event

A charity fundraiser seems like one big task, but it is actually many smaller ones.

Fundraising Gala:

  Venue and logistics:
    - Find and book venue
    - Arrange catering
    - Set up audio/visual equipment
    - Plan seating layout

  Fundraising mechanics:
    - Set fundraising goal
    - Design donation tiers
    - Organize auction items
    - Set up payment processing

  Outreach and marketing:
    - Design invitations
    - Manage guest list and RSVPs
    - Social media promotion
    - Press outreach

  Program:
    - Schedule of events for the evening
    - Speaker preparation
    - Entertainment booking
    - Volunteer coordination

Coaching a Youth Sports Team Through a Season

A coach decomposes a season into phases, and each practice into components.

Season level: Pre-season conditioning, skill development phase, team strategy phase, competition phase, post-season review
Practice level: Warm-up, individual skill drills, team exercises, scrimmage, cool-down and review
Game level: Starting lineup, substitution plan, offensive strategy, defensive adjustments, timeout usage

Decomposition in Technology

The same principle scales directly to technical problems.

Building a Web Application

When a team sets out to build a web application, trying to build "the whole app" at once is a recipe for failure. Instead, they decompose.

Web Application Decomposition:

  Authentication and user management:
    - User registration
    - Login/logout
    - Password reset
    - User profiles
    - Permissions and roles

  Database and data layer:
    - Database schema design
    - Data models
    - Migration scripts
    - Backup strategy

  User interface:
    - Page layouts
    - Navigation
    - Forms and input validation
    - Responsive design for mobile
    - Accessibility

  API layer:
    - Endpoint design
    - Request/response formats
    - Error handling
    - Rate limiting
    - Documentation

  Infrastructure:
    - Hosting and deployment
    - Domain and SSL
    - Monitoring and logging
    - Performance optimization

Each of these areas can be assigned to different team members or tackled in different sprints. A front-end developer works on the UI while a back-end developer designs the API. This parallel work is only possible because the problem has been well decomposed.

Debugging a Slow Application

When users report that an application is slow, a developer does not randomly change code hoping to fix it. They decompose the problem.

"The app is slow" decomposes into:

  Where is it slow?
    - Page load time
    - Specific actions (search, save, load data)
    - All pages or specific pages

  What layer is causing the slowness?
    - Network (slow API responses)
    - Database (slow queries)
    - Server processing (heavy computation)
    - Client rendering (too much UI work)

  When is it slow?
    - Always
    - Under heavy load
    - At specific times of day
    - For specific users or data sets

By decomposing "it is slow" into specific, testable subproblems, the developer can measure each component independently and find the actual bottleneck.

Writing a Business Report

Even a writing task benefits from decomposition.

Quarterly Business Report:

  Data gathering:
    - Revenue figures
    - Expense summaries
    - Customer metrics
    - Project status updates

  Analysis:
    - Quarter-over-quarter trends
    - Performance vs targets
    - Key wins and losses
    - Market context

  Writing:
    - Executive summary
    - Financial section
    - Operations section
    - Forward-looking section

  Review:
    - Fact-checking numbers
    - Peer review for clarity
    - Manager approval
    - Final formatting

The Decomposition Test

How do you know if you have decomposed well? Apply these checks:

Good decomposition:
  [x] Each subproblem can be understood on its own
  [x] Each subproblem can be worked on independently (mostly)
  [x] The subproblems are roughly similar in size
  [x] Solving all subproblems solves the original problem
  [x] No major aspect of the original problem is missing

Poor decomposition:
  [ ] One subproblem is 80% of the work (not broken down enough)
  [ ] Subproblems cannot be worked on without constant reference
      to other subproblems (too interdependent)
  [ ] Important aspects of the problem are not covered
  [ ] The pieces do not add up to the whole

Common Pitfalls

Not decomposing enough

The most common mistake is stopping too early. "Handle the food" for a wedding is not decomposed enough. It should be: choose a caterer, plan the menu, handle dietary restrictions, arrange tastings, confirm quantities, plan the bar. Keep breaking things down until each piece feels actionable.

Decomposing too much

The opposite mistake is breaking things into pieces so small that the overhead of managing them exceeds the benefit. You do not need to decompose "buy milk" into "open car door, sit in car, insert key." Use judgment about what level of granularity is helpful.

Decomposition is breaking a complex problem into smaller, manageable subproblems. It is typically the first step in problem-solving because you cannot address what you have not untangled.
Identify subproblems by asking: what are the parts, what comes first, who could handle this independently, and what types of work are involved.
Good decomposition enables parallel work, clearer thinking, and measurable progress on each piece.
The same skill applies to planning a vacation, opening a bakery, building a web app, or debugging a performance issue.
Keep decomposing until each piece is actionable, but stop before the overhead of managing tiny pieces outweighs the benefit.
Decomposition is iterative. Your first breakdown will evolve as you learn more about the problem. That is a sign of progress, not failure.