Unix and the Allure of Minimalism
At Heroku, engineers often cited the philosophy of building small, sharp tools: minimalist, composable programs whose combined effect exceeds what any single one could achieve. The canonical example is the Unix shell, where a set of focused utilities creates a powerful operating environment. Despite its origins in Unix, this mindset proved surprisingly adaptable to building modern web platforms.
The idea's best-known articulation appears in Eric S. Raymond's The Art of Unix Programming. The author distills Unix's overarching philosophy into a set of digestible rules, three of which stand out:
- Rule of Modularity: Write simple parts connected by clean interfaces.
- Rule of Composition: Design programs to be connected to other programs.
- Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
The book also situates this approach within a broader philosophical debate, noting that Unix thinking is not monolithic. As Raymond writes:
One strain of Unix thinking emphasizes small sharp tools, starting designs from zero, and interfaces that are simple and consistent. This point of view has been most famously championed by Doug McIlroy. Another strain emphasizes doing simple implementations that work, and that ship quickly, even if the methods are brute-force and some edge cases have to be punted.
Concrete examples of these principles in action are the shell primitives themselves: cd, ls, cat, grep, and tail. Through pipelines, redirections, and the file system, they combine into workflows none could produce alone. Their "simple and consistent" interfaces include shared conventions, such as common input idioms and standardized exit codes.
Small Tools in Web Architecture
This philosophy translates naturally to the web. Many modern applications are built as collections of services communicating over the network, a design with clear parallels to Unix programs operating through OS primitives. The recent rise of microservices—a philosophy of keeping services small for easier reasoning, operation, and evolution, also known as SOA—has made this model increasingly relevant.
The Pitfalls of Going Too Small
The trade-offs, however, are well understood. Small, sharp tools are not a universal solution. In discussing the spectrum between minimalist editors and comprehensive platforms, Raymond describes the risk of going too far:
Then the religion of "small, sharp tools", the pressure to keep interface complexity and codebase size down, may lead right to a manularity trap — the user has to maintain all the shared context himself, because the tools won't do it for him.
He continues later, noting a specific weakness:
Small, sharp tools in the Unix style have trouble sharing data, unless they live inside a framework that makes communication among them easy. Emacs is such a framework, and unified management of shared context is what the optional complexity of Emacs is buying.
This failure mode carries over directly to service-oriented systems. Consider two small, well-encapsulated programs handling account management and billing. Each is clean on its own, yet complexity can arise from the shared context between them. A monolithic system might ensure data integrity through a single ACID data store; separate programs must instead grapple with data drift and the complexity of distributed transactions. A recent incident illustrates the point: an internal identifier generated by a billing component, previously limited in use, was suddenly expected to be widely available. Backfilling that data required a slow, manual operation.
Finding the Right Boundaries
Raymond offers a guiding principle for selecting tool boundaries—the Rule of Minimality:
Choose the shared context you want to manage, and build your programs as small as those boundaries will allow. This is "as simple as possible, but no simpler", but it focuses attention on the choice of shared context. It applies not just to frameworks, but to applications and program systems.
Getting this wrong is easy. A team once set out to improve collaborative app management by introducing a new organization concept that would own an app and grant permissions to developers. Implementation proceeded as a separate service that enriched the user experience through the existing Heroku API. Initially lauded, the project soon revealed that the private API surface required by the new service swelled unmanageably, and the shallow integration forced extensive changes across both components for every new feature. It was ultimately re-integrated.
The mistake was clear: each service stayed simple in isolation, but combined complexity exceeded that of a single integrated system. The monolith, though less ideologically pure, simplified feature development, eased operations, and provided stronger data consistency guarantees.
"Small, sharp tools" deserves consideration in any architectural effort, but it cuts both ways. A tool can be too large—or too small. Service boundaries warrant deep scrutiny, and smallness is only worthwhile when it serves a purpose beyond itself.
