“Break the big problem into smaller ones” is common advice. But a longer task list does not automatically reduce complexity. Dependencies can remain tangled, information can disappear at hand-offs, and every small task may still be a one-off that must be reinvented next time.
Separate different rates of change#
Effective decomposition begins by observing what changes frequently and what remains stable. Separating components with different rates of change prevents one local adjustment from forcing the entire system to be rebuilt.
Content and presentation, rules and execution, or data collection and interpretation can often be separated through explicit interfaces. An interface is not a box on an organization chart; it is a verifiable agreement about inputs, outputs, and responsibility.
Make small problems independently testable#
A task may be short yet still be a poor module if it can only be judged at the end of the project. A useful small problem has a clear completion condition, receives feedback quickly, and contains the effect of failure.
Testability turns uncertainty into something manageable. The team can validate critical assumptions one at a time before expanding the investment.
Repetition creates a learning curve#
The overlooked benefit of modularity is repetition. When the same component, process, or decision is used many times, the team accumulates evidence about estimates, quality, and failure modes. Each improvement benefits later instances.
If every project is framed as a unique exception, experience does not transfer. Keeping a small truly custom layer while repeating the rest is often more reliable than pursuing a perfect one-off design.
Interfaces decide whether decomposition works#
Most post-decomposition cost appears at interfaces: whether information is complete, responsibility is clear, changes are communicated, and exceptions have an owner. Vague interfaces turn parallel work into waiting.
The goal is not a larger task list. It is a smaller set of stable agreements that make large uncertainty solvable as repeatable, testable problems.