Breaking a large task into pieces

Why split at all

A large task can't be estimated. Until it's decomposed, any estimate is guesswork.

It doesn't move. A two-week task sits in progress for a week and nobody, including you, knows how much is done.

It can't be reviewed. An enormous change can't be examined properly: the reviewer gives up at the third file.

It's easy to stall on. With an undefined mass ahead, sitting down to it is psychologically hard.

Signs a task is too big

• You can't name a duration except "a week or two".
• The description contains more than one verb: "build the form and set up the export".
• You don't know where to start.
• It touches several unrelated parts of the system.
• It can't be finished in one or two evenings.

The last is the most practical. The rule: if a piece doesn't fit into one or two sittings, split further.

Three ways to split

By user steps. The most natural. "User account area" splits into: sign in, view profile, edit profile, change password. Each piece is a complete action you can demonstrate.

By layers. Storage → logic → interface. It works, with a caveat: three weeks building storage that shows nothing is bad for motivation and risky, because a flaw in the design surfaces late.

Better to combine: take one scenario and build it through all the layers. A thin slice, but a working one.

By level of completeness. First the simplest working version, then improvements. A form with no validation → with validation → with hints → with draft saving.

Checking the result

After splitting, every piece should be:

• Comprehensible. It's clear what to do.
• Estimable. You can name a duration without guessing.
• Complete. The result shows whether it's done.
• Small. One or two sittings.

If a piece fails the check, split it further.

A common mistake: splitting into incomplete parts

Bad split: "build half the form". Unclear what that means or how to verify it.

Good: "the form accepts data and saves it, no validation" — then "add input validation". Both pieces can be shown and checked.

The principle: every piece should do something end to end, even in simplified form.

What about investigation

Sometimes you can't see how to approach it at all. Then the first piece isn't work but study: "find out how the exchange with this system works, half a day, then estimate the rest".

That's normal and honest practice. Far better than digging for a week under the guise of development.

On your own project

Decomposition is a skill built only by practice. Take your plan and break it into single-evening pieces. The first time it'll go badly: some pieces will turn out twice the size they looked.

That's normal, and it's exactly how the skill develops. After two or three projects you'll start seeing the hidden parts immediately.