Decomposing complexity

A real-world problem can contain too many people, rules, objects and actions to consider all at once. A model is a representation of selected features of that real-world situation. Before building a useful model or solution, it often helps to reveal the structure of the problem.

Suppose a school needs a digital system for booking seats at its summer showcase. Treating "build the booking system" as one task hides what the system must actually do. A first decomposition could be:

• manage performances, times and seat capacities;
• show available seats;
• make a booking and calculate its charge;
• cancel a booking;
• check in an attendee;
• produce attendance totals.

Each item names a responsibility of the whole system. A subproblem can be decomposed again. For example, make a booking can be split into checking availability, reserving the seat, calculating the charge, recording the booking and providing a booking reference.

This decomposition is useful in several connected ways:

Decomposition does not mean that the parts never interact. Making a booking depends on performance and seat information. The benefit is that the relationship can be stated clearly instead of being buried inside the original large problem.

It is also not simply a list of steps in time. "Open the site, choose a show, confirm" describes one journey through the system; decomposition identifies the smaller responsibilities that make the whole system work.

Abstracting relevant detail

Even after a problem has been split into parts, each part may contain a great deal of real-world detail. A model is useful because it is selective: it represents enough of reality for a particular purpose without trying to copy reality completely.

The word unnecessary always means "unnecessary for the stated purpose". A detail omitted from one model may be essential in another.

Consider a model used to choose a quick route for a school minibus:

Removing the house colours and owners' names reduces the amount of information that must be represented and considered. The important route relationships become easier to see, so the model is easier to analyse, understand and use to solve the route problem.

Now change the purpose. A model for an architectural survey might need building colours, ages and materials. Those details have not suddenly changed; their relevance has changed because the purpose is different.

A good abstraction is therefore simplified but still sufficient. Omitting a road closure would make the minibus model simpler, but less useful, because the removed detail affects the answer. Abstraction is not vagueness and it is not removing as much as possible.

Combining the techniques

Decomposition and abstraction both make complexity manageable, but they perform different jobs:

Return to the school showcase. The system has already been decomposed into responsibilities such as reserving a seat, calculating a charge and checking in an attendee. The developers can now abstract each responsibility:

This two-level view makes the real-world system easier to work with:

1. Model: the named components represent the main responsibilities, while each component represents only the details relevant to its purpose.
2. Analyse: a developer can inspect the reserve a seat responsibility and the information it needs without searching through every feature of the whole event.
3. Understand: meaningful component names show the shape of the system, and abstraction prevents irrelevant details from obscuring that shape.
4. Solve: developers can design solutions to the smaller, focused subproblems and then combine them into the complete system.

The order is not an absolute rule. A designer may abstract the situation first to decide the system boundary, or decompose first and then abstract each part. What matters is the distinction: decomposition splits the problem; abstraction filters the detail.

When explaining a benefit, name the change and its consequence. "It makes the problem easier" is too vague. "It lets the developer focus on one smaller responsibility, reducing the amount of complexity considered at once" identifies both what changes and why that helps.

Benefits of subprograms

Decomposition describes the structure of a problem or solution. In a program, a programmer can turn a suitable subproblem into a named program component.

For the showcase system, possible subprograms might be named showPerformances, reserveSeat, calculateCharge, cancelBooking and checkInAttendee. The names make the program's responsibilities visible. Calling calculateCharge means the rest of the program can use that task without showing all of its internal details at every point of use. This is abstraction inside the program.

Worked comparison: one rule, three places

Imagine that online bookings, desk bookings and telephone bookings all calculate the same ticket charge.

Copied design: the calculation is written separately in all three parts of the program. When the discount rule changes, three copies must be found and changed. Missing one copy could produce inconsistent charges.

Subprogram design: the calculation is written once in calculateCharge, and all three parts call that subprogram. The rule can be changed or corrected in one defined place, and every correct call uses the same version.

This example exposes several benefits:

Subprograms do not automatically make a program run faster, and they do not guarantee that it has no errors. Their benefits come from choosing sensible task boundaries, clear names and one dependable implementation of repeated or distinct responsibilities.