Let's Recommon IT

Small Enough to Understand

People can only govern what they can understand.

Thread:
Liberatory tech
Level:
metaconstitutional, in the theory column
File:
wiki/patterns/small-enough-to-understand.md

draft

explained in Who owns the machine?

Small Enough to Understand Sketch in perspective: a table with a shallow open tray on it, hatched, holding three small parts. In front of the table, one mannequin points into the tray; behind it, a second mannequin leans in and reaches for a part. Beside the tray, a dashed outline on the table top marks an empty space. The tray and its few parts are the system from the pattern's context: the hardware and software a group runs. Kept this small and open, it is the solution, the focus: a system small enough that everything can be seen at once. The pointing figure knows it; the reaching figure is a second member learning to run it, as the solution says, within a weekend. The dashed space is the solution's second half: room left for complexity, added only when a real need appears. The metaphor: a system as a tray of parts laid out on a table, not a sealed box only its builder can open.
Fig. 2

People can only govern what they can understand.

Context

Choosing hardware, software, and architecture for a household or community system.

Problem

Powerful, complex systems promise more features and scale. But a system that only one expert understands can only be maintained by that expert, and members can’t take part in decisions about something they can’t follow.

Forces

  • Tools past a certain size stop serving people and start controlling them (Tools for Conviviality).
  • Holistic technologies keep the whole process within reach of the people doing the work (The Real World of Technology).
  • Features and scale are visible up front. The cost of complexity shows up later, when the expert isn’t available.
  • Good places grow piecemeal, not from master plans (The Timeless Way of Building).

Solution

Therefore, keep the system small enough that a second member could learn to run it in a weekend, by adding complexity only when a real need appears.

Actions

  • One machine before a cluster, a plain Debian install before an orchestration platform, a few well-documented services before many.
  • Prefer well-documented, widely used software.
  • Write down why each new piece of complexity was added.

Consequences

  • Positive: more members can maintain the system and take part in decisions about it. Two Keyholders becomes realistic.
  • Negative: some features and scale come later or not at all, and members may get less convenience than a commercial service offers.

Mark up this page on GitHub