Hvordan træffer og dokumenterer du vigtige tekniske beslutninger?

Question

Accepted Answer

Vigtige tekniske beslutninger skal være **velovervejet, transparent og dokumenteret**, ikke truffet i nogens hoved og glemt. En god proces fremhæver afvejninger, bygger accept og efterlader et spor, så fremtidige ingeniører forstår *hvorfor*, ikke blot *hvad*.

## En beslutningsramme

```text
1. FRAME the problem and the constraints (cost, time, team skill, scale)
2. LIST the realistic options — usually 2-4, including "do nothing"
3. EVALUATE each against the constraints and trade-offs
4. DECIDE, and state the reasoning explicitly
5. RECORD it (ADR) and communicate it
6. REVISIT if assumptions change
```

## Registrer det med en ADR

En **Architecture Decision Record** er en kort, holdbar note:

```markdown
# ADR 014: Use PostgreSQL for the new service

## Status: Accepted

## Context
We need a primary datastore. Team knows SQL; data is relational; scale is moderate.

## Decision
Use PostgreSQL.

## Consequences
+ Strong consistency, team familiarity, rich querying.
- Vertical scaling limits later; revisit if write volume 10x's.

## Alternatives considered
DynamoDB (rejected: relational data, team unfamiliar).
```

## Afvejningen at styre

At dokumentere alt er overhead; at dokumentere ingenting mister institutionel hukommelse. Reserver ADR'er til beslutninger, der er **dyre at fortryde** eller som fremtidige ingeniører vil stille spørgsmålstegn ved.

## Hvorfor det betyder noget

Udokumenterede beslutninger bliver genoptaget endeløst, hver ny ingeniør spørger igen "hvorfor valgte vi det?"

At skrive begrundelsen op tvinger også klarhed: hvis du ikke kan retfærdiggøre det på papir, har du sandsynligvis ikke tænkt det grundigt igennem.