"There are no big problems in programming. Only small problems and those that haven't been broken up yet."

Why decomposition

Decomposition allows us to move at incredible speeds. We know it's better to focus on one task at a time. Focusing on one small task at a time has even more advantages:

• Routine energy boosts
• A routine sense of accomplishment
• Easier hand off mid-story
• Easier to take brakes
• Easier distraction management
• Faster velocity

How to decompose?

Start with a big problem like: "I need to find a bug in my web app."

Then find smaller problems which will lead you to resolving the problem. With this problem, I would think: "I know there's a frontend, server, and data layer... The bug could be in any of those."

Now we have 3 smaller problems instead of 1 big one. When I try to tackle big problems, I find myself reviewing all of the code multiple times. By tackling one of these smaller problems, we can remove a section of code entirely and narrow our focus to productive exploration.

When you find you're stuck with a big problem again, repeat. Let's say we find out the front end is relatively simple. As is the datalayer. Neither contains the bug we're tracking. The server method is 1000 lines long and has 6, 1000 line subroutines. This is a big problem. There are two ways we could break this new big problem down further.

1. Binary search: run down to line 500 and see if it occurs. Then run down to 250, 125, and so on till you pinpoint the problem.
2. Break it up by subroutine. Take each one individually and find whether the problem is occuring in that area. Once you find which routine it's happening in, figure out how to break it up from there.

Both of these techniques are useful in different situations. Without more context, we don't know which one will be applicable.

Review

1. Find a big problem.
2. Break that problem up into smaller problems.
3. Repeat steps 1 + 2.

Agile

Decomposition pre-coding is just as effective as during a code session. I was talking to my scrum master, Andy, last week about epics, features, and stories.

He said that an epic is a big goal we're trying to accomplish like, "Add authentication to the web app." A feature would be one feature required for the epic like, "Add a button for sign in." And a story would be one portion of the feature like, "Get the button to show up" or "Add a method to the backend to receive the login request."

I like the definitions Andy uses because they align well with decomposition. When you start to work on a story, it can already be decomposed into a small unit of work.

Where to go from here

The next time you run into a big problem, remember: there are no big problems in programming. There are only small problems and those that haven't been broken up yet.