Stacking Functions
pattern established
Source: Agriculture → Systems Thinking, Software Engineering
Categories: biology-and-ecologysystems-thinking
From: Agricultural Proverbs and Folk Wisdom
Transfers
In permaculture design, “stacking functions” means that every element in the system should serve multiple purposes. A chicken is not just an egg producer — it is also a pest controller (eats insects), a soil tiller (scratches and turns surface soil), a fertilizer producer (manure), a heat source (in a greenhouse), and a food waste processor (eats scraps). The design question is not “what does this element do?” but “how many functions can this element serve simultaneously?”
The principle is the inverse of industrial specialization. Where industrial design optimizes each component for a single function (the combine harvester only harvests, the tractor only pulls, the sprayer only sprays), permaculture optimizes the connections between components so that each one participates in multiple subsystems.
Key structural parallels:
-
Connection density over component count — a stacked-function design has fewer discrete elements but more relationships between them. Each relationship is a pathway for energy, material, or information to flow from one subsystem to another without external intervention. In software, this maps onto the difference between a platform with many single-purpose microservices connected by explicit API calls and a well-designed monolith where shared data structures and co-located logic reduce the overhead of inter-component communication. The stacked-function approach reduces the total number of interfaces while increasing the work done per interface.
-
Redundancy through overlap, not duplication — in a stacked-function system, if the chicken dies, you lose pest control, tillage, fertilizer, and heat simultaneously. But you also have a duck that partially covers pest control and fertilizer, and a compost system that partially covers tillage. The redundancy is not through identical backups (two chickens) but through overlapping function coverage (different elements that share some functions). In infrastructure engineering, this maps onto the distinction between N+1 redundancy (a spare identical server) and graceful degradation (multiple different systems that each partially cover the others’ functions).
-
Efficiency at steady state, fragility under shock — a stacked- function system is remarkably efficient when everything is working: fewer inputs, less waste, more output per element. But precisely because functions are shared across elements, a single failure cascades across multiple subsystems. Losing the pond that provides irrigation, fish protein, microclimate cooling, and fire protection simultaneously is worse than losing a dedicated irrigation pipe. In software, a “god object” that centralizes logging, configuration, authentication, and data access is efficient until it needs to be changed, at which point every modification risks breaking four unrelated functions.
-
The design constraint is knowledge, not materials — stacking functions requires understanding the relationships between elements well enough to identify non-obvious synergies. A novice gardener puts a fruit tree in the yard and a chicken coop in the corner. An expert puts the chicken coop under the fruit tree so the chickens eat fallen fruit (pest control), their manure fertilizes the tree, and the tree shades the coop in summer. The elements are identical; the design knowledge is different. In API design, a junior engineer builds separate endpoints for each use case. A senior engineer designs a single endpoint with composable parameters that serves multiple use cases through the same interface.
-
It requires maturity and stability — in a mature permaculture system, stacked functions have co-adapted over years of iteration. The right chicken breed for your climate, the right tree species for your soil, the right spatial arrangement for your water flow — these are discovered through observation, not prescribed in advance. The pattern works best in stable systems where the designer has had time to observe interactions. It works poorly in greenfield environments where the interactions are unknown.
Limits
-
Natural systems evolved their stacking; engineered systems are designed under pressure — the fruit tree that serves six functions has been optimized by natural selection across geological time. The software module that serves six functions was written during a sprint and has not been optimized by anything except deadline pressure. The agricultural metaphor implies a harmony and efficiency that engineered systems rarely achieve. In practice, multi-function software components tend to serve all their functions mediocrely rather than achieving the elegant integration the permaculture example suggests.
-
Stacking increases coupling — every additional function assigned to an element is an additional reason to change that element and an additional stakeholder affected by changes to it. In software this is directly measurable: a module with high afferent and efferent coupling is expensive to modify, hard to test in isolation, and resistant to refactoring. The pattern’s agricultural framing obscures this cost because biological systems do not have “releases” or “deployment pipelines” — the chicken does not need a code review before it starts eating insects.
-
It conflicts with the separation-of-concerns principle — in software engineering, the dominant design heuristic is the opposite of stacking functions: each module should have one responsibility, one reason to change. The Single Responsibility Principle exists precisely because stacking functions in code produces the maintenance nightmares that permaculture’s biological examples do not suffer from. The pattern is structurally valid but its application domain matters enormously: it works better in physical systems with slow change rates than in software systems with fast change rates.
-
Correlated failure modes are hidden — the efficiency of stacking is visible and celebrated. The fragility of stacking is hidden until a failure occurs. A farm where the pond serves irrigation, aquaculture, fire protection, and microclimate regulation looks brilliant until the pond dries up in a drought and all four functions fail simultaneously. The pattern’s proponents tend to emphasize steady-state efficiency and underweight correlated failure risk. In infrastructure, this is the argument against running your database, cache, and message queue on the same server — it is efficient until the server dies.
-
It assumes the designer can predict interactions — stacking functions requires understanding second- and third-order interactions between elements. In simple agricultural systems with well-understood biology, this is feasible. In complex software systems, organizational structures, or policy design, the interactions between functions are often emergent and unpredictable. Stacking functions you do not fully understand produces not elegant multi-use but opaque entanglement.
Expressions
- “Each element performs multiple functions” — Mollison’s canonical formulation in Permaculture: A Designers’ Manual
- “Stacking functions” — the compressed term used in permaculture design courses and sustainable agriculture literature
- “Multi-use” or “multi-purpose” — the generic design vocabulary for the same principle, applied in product design and urban planning
- “Swiss Army knife” — the consumer product that embodies the pattern, used colloquially to describe any tool or component that serves multiple roles
- “God object” or “god class” — the pejorative software term for stacking taken too far, where a single component accumulates so many functions it becomes unmaintainable
- “Do one thing well” — the Unix philosophy counter-principle, which explicitly rejects function stacking in favor of composable single- purpose tools
- “Platform play” — business strategy term for designing a product that serves multiple market functions (marketplace, payment processor, identity provider) through a single integrated system
Origin Story
The principle originates in Bill Mollison and David Holmgren’s permaculture design system, developed in Tasmania in the 1970s and formalized in Mollison’s Permaculture: A Designers’ Manual (1988). The design method drew on observation of natural ecosystems, traditional agricultural practices, and systems ecology.
In natural ecosystems, function stacking is the norm rather than the exception. A single mature oak tree provides habitat for hundreds of species, stabilizes soil, cycles nutrients, moderates microclimate, sequesters carbon, and produces food (acorns) for wildlife. Mollison’s insight was that human agricultural systems had progressively un-stacked functions through industrialization — replacing multi- function elements (the farmyard chicken) with single-function inputs (the commercial pest spray, the synthetic fertilizer, the industrial egg operation) — and that this un-stacking was a primary source of both ecological damage and economic fragility.
The principle entered technology discourse through the sustainability and systems thinking movements. In software architecture, it maps imperfectly but provocatively onto ongoing debates about microservices versus monoliths, the Single Responsibility Principle versus pragmatic consolidation, and platform strategy versus point solutions. The tension between stacking (efficiency, reduced redundancy) and separation (maintainability, independent deployability) is one of the enduring structural tensions in system design across domains.
References
- Mollison, B. Permaculture: A Designers’ Manual (Tagari Publications, 1988) — the primary source for the principle and its design methodology
- Holmgren, D. Permaculture: Principles & Pathways Beyond Sustainability (Holmgren Design Services, 2002) — develops the principle within a broader ethical and design framework
- Martin, R.C. Clean Architecture (Prentice Hall, 2017) — the Single Responsibility Principle as the software engineering counter- argument to function stacking
- Newman, S. Building Microservices (O’Reilly, 2015) — the architectural pattern that operationalizes separation of concerns, the structural opposite of stacking
- Meadows, D. Thinking in Systems: A Primer (Chelsea Green, 2008) — systems thinking framework for evaluating the tradeoffs of integration versus separation
Related Entries
Structural Neighbors
Entries from different domains that share structural shape. Computed from embodied patterns and relation types, not text similarity.
- The Ensemble (theatrical-directing/mental-model)
- Open Stairs (architecture-and-building/pattern)
- Staircase as a Stage (architecture-and-building/pattern)
- The Registry Pattern (governance/archetype)
- Network of Learning (architecture-and-building/pattern)
- Work Community (architecture-and-building/pattern)
- Nemawashi (horticulture/metaphor)
- Companion (food-and-cooking/metaphor)
Structural Tags
Patterns: superimpositionlinkpart-whole
Relations: coordinateenable
Structure: network Level: specific
Contributors: agent:metaphorex-miner