23Teknologi

Galls lov

Komplekse systemer, der virker, er typisk vokset ud af simple systemer, der virkede — de designes sjældent færdige fra scratch.

Kort fortalt

Galls lov hævder, at et komplekst system, der virker, næsten altid har udviklet sig fra et simpelt system, der virkede. Et komplekst system designet fra bunden plejer ikke at virke — og kan ikke let repareres til at gøre det.

Hvad betyder princippet?

John Gall formulerede observationen i Systemantics (1975) som en advarsel mod overambitiøs systembygning. Budskabet er evolutionært: start småt, få feedback, udvid.

Loven bruges ofte i software og organisationsdesign som argument for inkrementel kompleksitet frem for big bang.

Få noget til at virke simpelt først. Kompleksitet fortjenes.

Et konkret eksempel

Et team forsøger at lancere en fuld platform med ti integrationer på dag ét. Intet hænger sammen i produktion. Et andet team lancerer én kerneflow, lærer af brugen og tilføjer integrationer én ad gangen — og ender med et mere robust, om end stadig komplekst, system.

En “perfekt” procesmanual skrives, før nogen har prøvet arbejdet. Den fejler ved kontakt med virkeligheden. En simpel checklist, der opdateres efter erfaring, skalerer bedre.

Hvornår er princippet nyttigt?

  • Når greenfield-projekter sigter efter totalarkitektur fra start.
  • Når man planlægger MVP og iteration.
  • Når kompleksitet forsvares uden driftserfaring.
  • Når man vurderer omskrivninger versus evolution.

Begrænsninger og kritik

Nogle systemer har mindstekrav til kompleksitet (sikkerhed, regulering, fysisk infrastruktur). Galls lov er en tendensobservation, ikke bevis for, at al forberedelse er spild.

Den siger heller ikke, at man aldrig må designe. Den siger, at virkelighedstest af en simpel kerne normalt slår spekulativ perfektion.

Kilder

  1. John Gall, Systemantics (1975) — formulering af Galls lov.
  2. Bemærkning: Loven er en systemteoretisk heuristik, ofte citeret i softwarepraksis.
  • 12Conways lovSystemers arkitektur spejler kommunikationsstrukturen i den organisation, der designer dem.
  • 34KISS-princippetHold løsninger så enkle som muligt — kompleksitet bør være begrundet, ikke standard.
  • 66YAGNIYou Aren't Gonna Need It: byg ikke funktionalitet, før du faktisk har brug for den.
  • 14DRY-princippetDon't Repeat Yourself: undgå at den samme viden findes i flere, uafhængige kopier, der kan komme ud af sync.