Software Design Foundations
Work from the diagnosis that complexity is the core problem down to the concrete techniques that keep code understandable: hiding decisions, deep modules, precise names, and obvious code.
- Depth
- Introductory
- Steps
- 9 existing graph entries
- 1
Complexity Is the Root Cause
Complexity, especially the accidental complexity we introduce ourselves, is the dominant source of difficulty in software, so the highest leverage work is relentlessly reducing it. The enemy is not lines of code or scale but the loss of understandability as a system grows. Com...
Start from the diagnosis: complexity, not any single technology, is what makes software hard to change.
Related within this path
- References: Complexity
- References: Essential vs Accidental Complexity
- 2
Complexity
Anything about the structure of a system that makes it hard to understand and modify. Complexity is defined by how the system appears to the people working on it, not by its size or line count. Complexity is the primary force that slows software development over a system's lif...
Define complexity operationally as what makes a system hard to understand and modify.
Related within this path
- References: Complexity Is the Root Cause
- References: Complexity Should Be Hidden
- Related To: Deep Modules
- Related To: Essential vs Accidental Complexity
- Related To: Information Hiding
- Related To: Pull Complexity Downward
- 3
Essential vs Accidental Complexity
A distinction between complexity inherent in the problem itself (essential) and complexity introduced by the tools, representation, and accidents of how we build the solution (accidental). In No Silver Bullet, Brooks argues software's essential complexity, its intricacy, confo...
Separate the complexity inherent to the problem from the complexity we add ourselves.
Related within this path
- References: Complexity Is the Root Cause
- Related To: Complexity
- 4
Information Hiding
Each module encapsulates a few design decisions inside its implementation, and those decisions are not visible in its interface. The opposite, information leakage, is when one design decision is reflected in multiple modules. Information hiding is the mechanism that makes modu...
The core technique: keep each design decision inside one module.
Related within this path
- References: Complexity Should Be Hidden
- Related To: Complexity
- Related To: Deep Modules
- 5
Deep Modules
A module is deep when it offers a simple interface over a powerful implementation. Depth is the ratio of functionality provided to interface exposed: the best modules hide a lot behind a little. A module's interface is a cost paid by every user; its implementation is a cost pa...
Prefer modules that hide a lot of capability behind a small interface.
Related within this path
- References: Complexity Should Be Hidden
- Related To: Complexity
- Related To: Information Hiding
- Related To: Pull Complexity Downward
- 6
Pull Complexity Downward
When complexity is unavoidable, it is better to absorb it inside a module's implementation than to expose it through the interface. The module developer suffers so that every user does not. An interface's complexity is paid by everyone who uses the module, repeatedly, forever;...
Where complexity is unavoidable, absorb it inside the module rather than pushing it onto callers.
Related within this path
- References: Complexity Should Be Hidden
- Related To: Complexity
- Related To: Deep Modules
- 7
Naming
A name is a tiny abstraction. A good name creates a precise, accurate image of the thing it refers to and quietly excludes what it is not. Names should be precise enough that a reader rarely has to look at the implementation, and consistent enough that the same word always mea...
Apply the same clarity at the smallest scale: precise names as tiny abstractions.
Related within this path
- Related To: Obvious Code
- 8
Obvious Code
Code is obvious when a reader can understand what it does and why with little effort, forming a correct mental model on the first read and rarely being surprised. Nonobvious code is the enemy. Code is read far more often than it is written, and obviousness is a property judged...
Aim for code a reader understands correctly on the first pass.
Related within this path
- Related To: Naming
- 9
Complexity Should Be Hidden
Complexity is inevitable, but it should be concealed behind simple interfaces and pushed down and inward, so that most people most of the time never have to confront it. The quality of a design is measured by how little complexity it exposes, not by how clever its internals ar...
Close on the worldview these techniques serve: complexity belongs hidden behind simple interfaces.
Related within this path
- References: Complexity
- References: Deep Modules
- References: Information Hiding
- References: Pull Complexity Downward