Saltar a contenido

Como Tomar y Documentar Decisiones de Ingenieria

Proposito

Framework practico para tomar decisiones tecnicas de forma estructurada, comunicarlas al equipo, y documentarlas para el futuro.

1. Cuando Documentar una Decision

No todas las decisiones necesitan un ADR. Documenta cuando:

  • La decision es dificil de revertir (elegir base de datos, lenguaje, framework).
  • Afecta a multiples personas o componentes.
  • Tiene trade-offs significativos (no hay opcion "obviamente mejor").
  • Sera cuestionada en el futuro ("por que hicimos esto?").

No documentes: - Decisiones triviales (nombre de una variable, formato de un log). - Decisiones que siguen un patron establecido ("usamos el mismo patron que el otro servicio").

2. Framework para Tomar Decisiones

Paso 1: Definir el Problema (no la solucion)

MAL:  "Debemos usar Redis?"
BIEN: "La busqueda de disponibilidad tarda 2s (p95). Necesitamos reducirla a <500ms."

El problema bien definido abre mas opciones. Si empiezas con la solucion, te cierras a alternativas.

Paso 2: Listar Opciones (minimo 2)

Siempre evalua al menos 2 opciones. Si solo tienes una, no es una decision, es una imposicion.

Para cada opcion: - Pros (que ganamos) - Contras (que perdemos o arriesgamos) - Costo (tiempo de implementacion, complejidad operativa, precio) - Reversibilidad (que tan facil es cambiar de opinion despues)

Paso 3: Definir Criterios de Decision

Antes de comparar opciones, define que criterios importan y cuanto pesan:

Criterio Peso Por que
Tiempo de implementacion Alto Tenemos deadline en 3 semanas
Familiaridad del equipo Alto No hay tiempo para curva de aprendizaje
Costo operativo Medio Presupuesto limitado pero no critico
Escalabilidad Bajo No esperamos escalar en 6 meses

Paso 4: Decidir y Documentar

Elige la opcion que mejor satisface los criterios. Documenta: - Que decidiste. - Por que (razonamiento, no solo la conclusion). - Que descartaste y por que. - Cuando reconsiderar (bajo que condiciones cambiarias de opinion).

Paso 5: Comunicar

  • Comparte la decision con el equipo (Slack + link al ADR).
  • Da un deadline para objeciones (ej: "si no hay objeciones antes del viernes, procedemos").
  • Escucha feedback y ajusta si es necesario.

3. Ejemplo: Decision Real del Sistema de Turnos

Problema

Dos pacientes pueden reservar el mismo slot al mismo tiempo (race condition).

Opciones

Opcion A: Bloqueo Pesimista (SELECT FOR UPDATE) - Pros: Simple, garantiza consistencia, PostgreSQL lo soporta nativamente. - Contras: Bloquea la fila durante la transaccion (puede causar contention con alta concurrencia). - Costo: Bajo (cambiar una query). - Reversibilidad: Alta (quitar el FOR UPDATE).

Opcion B: Bloqueo Optimista (version column) - Pros: No bloquea filas, mejor para alta concurrencia. - Contras: Requiere manejar conflictos en el codigo (reintentos), mas complejo. - Costo: Medio (agregar columna de version + logica de reintento). - Reversibilidad: Media.

Opcion C: Unique Constraint en BD - Pros: La BD garantiza unicidad, no se puede violar. - Contras: Requiere tabla adicional (reserved_slots), el error de unique violation no es descriptivo. - Costo: Medio. - Reversibilidad: Media (migracion para agregar/quitar tabla).

Criterios

Criterio Peso
Simplicidad Alto (equipo pequeno, MVP)
Correctitud Critico
Performance Bajo (200 bookings/dia, no hay contention real)

Decision

Opcion A: SELECT FOR UPDATE porque es la mas simple, es correcta para nuestro volumen, y es facil de revertir. Con 200 bookings/dia, la contention es despreciable.

Reconsiderar si: El volumen supera 1000 bookings/dia concurrentes.

4. Patrones de Decisiones

"Two-Way Door" vs "One-Way Door" (Amazon)

  • Two-way door (reversible): Decide rapido, ajusta despues. Ej: estilo de API, nombre de un servicio, herramienta de testing.
  • One-way door (irreversible): Invierte tiempo en analizar. Ej: lenguaje de programacion, base de datos, modelo de datos core.

"Last Responsible Moment"

No decidas antes de lo necesario. Espera hasta tener la informacion suficiente, pero no tanto que la indecision bloquee al equipo.

"Disagree and Commit"

Si el equipo no llega a consenso, el tech lead o la persona con mas contexto decide. Los demas se comprometen con la decision aunque no esten 100% de acuerdo.

5. Anti-patrones de Decision

Anti-patron Problema Fix
Decision por comite Nadie decide, se pierde tiempo Un decisor claro por tema
Analysis paralysis Se analizan 10 opciones durante semanas Limitar a 3 opciones, deadline de 3 dias
HiPPO (Highest Paid Person's Opinion) Se elige la opcion del jefe sin evaluar Criterios objetivos definidos antes de comparar
Decision sin documentar En 6 meses nadie sabe por que se eligio X ADR para decisiones significativas
Reabrir decisiones constantemente Inestabilidad, retrabajos Respetar el "Disagree and Commit"

Checklist de Completitud

  • Framework de 5 pasos documentado
  • Ejemplo real aplicado al sistema de turnos
  • Patrones de decision (two-way door, LRM)
  • Anti-patrones documentados
  • Revisada por otro ingeniero

Archivos relacionados