Simplicity First

Core Idea

Examples and diagrams in this page follow the shared Hypothetical Scenario.

Most teams first notice complexity during a high pressure release. A routine change suddenly needs deep code navigation. Review time grows and defect risk grows. That moment usually signals weak responsibility boundaries.

Simplicity lowers cognitive load and defect rate. Simplicity starts with responsibility. A unit with one responsibility is easier to read, test, and change. Complexity grows when one unit carries many duties.

Conceptual Overview

Consider a common sprint scenario. A small feature request lands near the end of a cycle. The change looks local at first glance. Then one function touches validation, policy, storage, and transport. The team now carries four change risks for one ticket.

A software task often includes many concerns. Input validation, domain rules, storage, and transport are different concerns. One large function that mixes these concerns becomes hard to reason about. Small edits then trigger side effects in unrelated behavior.

Responsibility gives a clear split rule. Give each unit one duty and one reason to change. This is the Single Responsibility Principle. It turns a large problem into smaller manageable problems. Each problem gets a small unit with clear scope.

Example: An endpoint that refreshes car matches can be split into focused units. One unit validates payload shape. One unit applies business rules. One unit saves state. One unit emits an audit event. The endpoint composes these units in order. Teams can change one unit with low risk to others.

Responsibility splitting view. One mixed unit is hard to maintain. Focused units keep duties clear.

Responsibility and Single Responsibility Principle

Responsibility is the boundary of behavior ownership. Single Responsibility means one unit owns one behavior axis. A change in pricing policy should not force storage edits. A change in storage engine should not force policy edits.

This principle keeps complexity local. It limits each file to a narrow mental model. It supports short tests that target one duty. It supports code review with clear intent.

What Problem Splitting Solves

Large unstructured problems hide failure paths. They force engineers to load many rules at once. They mix business meaning with technical mechanics. They slow delivery and raise regression risk.

Problem splitting fixes this. Each unit solves one part of the system behavior. Composition combines units into full workflows. The system keeps feature depth without becoming opaque.

Blast radius comparison. Mixed duties spread edit impact. Focused duties keep impact local.

Relationship to Abstraction and Boundaries

Abstraction defines the promise of a unit. Boundary defines the edge of that promise. Responsibility defines what the unit owns inside that edge. Simplicity appears when these three stay aligned.

If boundaries leak, simplicity drops. If abstractions are vague, composition breaks. If responsibilities overlap, edits spread across modules. Clear boundaries and focused responsibilities preserve simple systems.

Easy to Understand, Test, and Change

Simple code is readable in minutes. A new engineer should find the flow and intent quickly. Names should state business meaning. Hidden side effects should stay out of core logic.

Simple code is testable with small focused tests. Each unit test should target one behavior rule. Tests should run fast on a laptop. Teams should avoid network calls in unit tests. Integration tests should cover boundary crossings and contracts.

Simple code is changeable with low blast radius. A feature update should touch a small set of files. A bug fix should stay inside one responsibility area. If one change request touches many modules, the split is weak. That signal should trigger a refactor task.

Use clear checks to track this property over time. Track median files changed per ticket. Track test runtime for a pull request. Track rollback rate after production release. These numbers show if simplicity is rising or falling.

Simplicity signal map. Readability, test speed, and change scope are key checks. Track these checks over time.

Computing History

In 1972, David Parnas framed modules around change impact. This guided engineers to split systems by responsibility. In 1975, Fred Brooks described complexity as a core software burden. Small focused units became a practical way to control that burden. Unix culture reinforced this pattern with small composable tools.

Sources: Parnas (1972), Brooks (1975), and Ritchie (1993)

Quote

"Controlling complexity is the essence of computer programming."

Source: Edsger W. Dijkstra, 1976

Practice Checklist

• State one responsibility for each module in docs.
• Keep functions short and single purpose.
• Split mixed concerns into separate units before feature growth.
• Compose workflows from focused units.
• Keep module contracts explicit and narrow.
• Add tests per responsibility unit.
• Keep unit tests fast and deterministic.
• Track files changed per ticket and rollback rate.

Written by: Pedro Guzmán

See References for complete APA-style bibliographic entries used on this page.