Design by Decomposition

“Can’t see the wood for the trees?”
“Can’t see the trees for the wood?”
“You can’t break a bundle of sticks.”

We need to break down the problem, whether at project, component or item levels. I call this approach “Design by Decomposition”

We all do it as part of the software development process. “Design by Decomposition” places process and structure around the technique. Like all processes in design, use it as a guideline, not a fixed rule.

Search Google for “The Rule of Threes“. You will find examples in painting, photography, design, drama, speech writing, presentations, comedy and problem solving. Don’t get lost – it makes fascinating reading.

Why is “The Rule of Threes”so common in human communication? Decimal is for the fingers, binary for the computer and ternary for the mind.

  • Give me a list of 10 choices and I have to re-read it over and over. Give me choices of three where the third is none of the above and I can quickly drill down.
  • Tell me 10 benefits of your product and I won’t remember any. Tell me three and I will remember them all.
  • I can list my 3 favourite colours over and over consistently, but not 10. Same for food, actors or relatives 🙂

For a project, a sample decomposition could be:

  1. The Vision
  2. Design
    1. User Interfaces
      1. Web
      2. Mobile
      3. Integrations
    2. Business Logic
      1. Domain Group 1
      2. Domain Group 2
      3. Domain Group 3
    3. Data Access
      1. Database
      2. SOA
      3. Cloud
  3. Environment
    1. Architecture
    2. Frameworks
      1. Web
      2. Server
      3. Database
    3. Hardware

For components and items, the groups of three are more likely domain specific.

Here is a sample item decomposition.

Task: Read in CSV files and make the data available by column name. Account for large files.


  1. Read a CSV file
    1. Find and use Java library
    2. Access CSV as a list of maps
    3. Call closure for each row
  2. Format Variations
    1. Header Lines
    2. Differing separator
    3. Different quote
  3. Edge conditions
    1. Quoted items
    2. Multi-line items
    3. Empty file

I know it looks artificial to keep to “The Rules of Three“, but there is a benefit apart from recognition. When a level has 2 items it forces you to think of a third. When a level grows it forces a refactor into groups. Thinking is good as it highlights problems and areas that need improvement. Don’t make the rule a law, but give it a go.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s