2 Fundamental ↑

No. 9 — Decomposition

Large and complex things should be broken down into smaller, more manageable things. This can be done progressively, and recursively, at multiple levels.

It’s best if the number of things in each group is somewhere in the range of 3 - 15, with 7 being a sweet spot. The human brain seems fairly good at dealing with sets of this size.

This idea can be applied to system functionality, to software architectures, to work statements (where it results in a work breakdown structure), and to project staffing.

Decomposition is particularly powerful when done in conjunction with Cohesion and Loose Coupling.

One famous example of decomposition was performed by the Wright Brothers when they broke down the problem of human flight into three separate domains: lift, control and propulsion.

Another common example of decomposition in modern web applications is evident in the popular MVC pattern, in which application logic is subdivided into three separate areas: model, view and controller.

In Agile, it is common to have three levels of requirements decomposition, starting with epics, proceeding to features, and then to user stories.

Note, however, that detailed decomposition of requirements need not be done initially, and can often be profitably deferred until a feature is a high enough priority to be approaching scheduled implementation into code.

Words from Others on this Topic

Next: Cohesion