It is commonly believed that decomposition is a good thing. It is indeed useful: it allows us to eliminate uncertainty by breaking down a large, unclear problem into smaller, manageable parts. During the decomposition process, we can better understand the scope of work and even design along the way.
However, excessive decomposition can be dangerous. It creates the illusion that a feature consists solely of the technical tasks we have broken it down into.
Decomposition incurs overhead costs, not only for creating and working on individual tasks but also for maintaining separate lifecycles and implementing and rolling out each task separately.
The requirement for decomposition can lead to premature design and planning. In order to decompose, design decisions are made without all the necessary information. And when new information appears, it may not be corrected. We may feel compelled to implement the previously decomposed plan.
Decomposition creates an illusion of control. Doing half of the subtasks means you’ve completed half of the feature. Completing all the subtasks means you’ve completed the entire feature. This is not the case. To complete a feature, it is not enough to complete all of its subtasks. The feature is usually more than just the sum of its parts. There is emergent behavior, a value that is given by the combination of the results of the subtasks and which is not present in the simple sum of these results. To complete the feature, this value must also be implemented.
Often, decomposition simply doesn’t make sense. For example, if a feature is simple enough and can be completed in one go.
Feature decomposition is relevant when we break it down by delivery: into pieces that are themselves the end result in terms of product or a use case.
There is no need to decompose a feature into works (for example, “develop a frontend”, “develop a backend”, or “write a migration”). It is better to decompose it into separate “pieces of value”.
Decomposition should not be a substitute for documentation or a task description. The description should make it clear what should be the result and what should not be forgotten. But not necessarily each of these items should be a separate subtask.
Another case is when the task is formulated not in terms of value, but in terms of work to be done. In this case, it may be appropriate to decompose it into independent sub-works.
With the seemingly obvious benefits of decomposition, it can easily become a “fifth wheel”. Like any other management tool, it should be used consciously.
Top comments (0)