Why Decomposition Matters

As children, we were told by adults to take smaller bites when eating. We didn’t always understand the risk of choking that they saw, but ultimately it was easier and safer to chew those smaller bites. In some cases, taking smaller bites made the difference in finishing more of the meal. But have we translated that lesson to other things in our lives?

Often we try to tackle things that are too big to sufficiently understand, estimate, or complete in a reasonable amount of time and we suffer for it. We don’t always see the risks that hide in more complex items and thus don’t feel compelled to break them down. Other times we fail to break things down due to unknowns, ignorance, uncertainty, pride, optimism, or even laziness.

Variation in Software

Delivering software products is a constant struggle with a variation of size and complexity. It’s everywhere, from the size of user stories to tasks to code changes to releases. It is present from the moment someone has an idea to the moment software is deployed. We strive to understand, simplify, prioritize and execute on different types of things that are difficult to digest. The more variation we see, the more we struggle with staying consistent and predictable.

Because of this variation, we need to be good at breaking things down to more manageable sizes. This need is so pervasive, I propose it be viewed as a fundamental skill in software. I don’t think most teams recognize this and certainly don’t develop the skill. Many people on Agile teams exposed to concepts like Story decomposition don’t often realize how often they need to apply similar practices in so many other ways.

Why Decomposition Matters

My example of eating small bites was simplistic. In developing software, there is a lot more to gain but it is still ultimately about reducing risk and making tasks easier.

Progress

According to The Progress Principle, a strong key to people remaining happy, engaged, motivated, and creative is making regular progress on meaningful work. Not surprisingly, we want to get things done, but we also want to feel a sense of pride and accomplishment.

Of course, stakeholders and other parties are interested in seeing progress from those they depend on. When we are able to make more regular progress toward goals, we provide better measurements and visibility for ourselves and others to know how we are doing.

It should be no surprise that smaller items enable quicker progress toward goals if done right. We certainly need to take care to avoid dependencies and wait time. Smaller, more independent goals allow more frequent progress and all the benefits that come with it.

Collaboration

As we have more people working on something, is it easier to put them all on a larger, more monolithic task or divide and conquer? Usually, we prefer to divide and conquer. Yet how we divide is important as well because dependencies and other kinds of blocking issues create wait time and frustration.

Decomposition can be one of the easier ways to get additional people involved with helping accomplish a larger goal. By breaking up work into more isolated items to be done in parallel, we are increasing the ability to swarm on a problem.

Complexity

Complexity is one of the greatest challenges in software development. With more interactions, operations, and behavior,s we are more likely to have edge cases and exposure to risk when anything changes. Large goals are easier places for complexity to hide. The larger the task is when we try to accomplish it, the more details we have to discover, understand, validate, and implement.

Focusing on smaller units of work can be a helpful constraint we place on ourselves. Why add our own constraints? When we constrain ourselves to work on a small portion of a larger task we are trying to limit the complexity that prevents us from accomplishing something. We want to avoid a downward spiral of “what if?” and “we are going to need” scenarios that, while important, can slow the task at hand and lead to overthinking and overdesigning and accumulating work we may never need. We are trying to avoid Analysis Paralysis.

Control

By looking at Kanban systems we can see wide variations in size can impact lead times. If we can be more consistent with the size of items flowing through a system then we will have more consistent throughput and cycle times. By breaking down work items more frequently into items of similar size cycle times become more stable and the average size (due to whatever size variation remains) becomes more useful for forecasting due to the law of large numbers.

Clarity

It isn’t a coincidence that Break It Down is also a slang phrase appearing in music and pop culture that also relates to our goals. Urban Dictionary defines “Break It Down” to mean: To explain at length, clearly, and indisputably. By looking at the pieces of a larger whole individually and in more details we can often gain more clarity and understanding of the bigger picture than if we had never spent the extra effort.