En 2024, nuestro equipo cerró 47 tickets. En 2025, cerramos 12 — y el producto anduvo mejor. Este post es sobre los 35 tickets que elegimos no resolver, y lo que aprendimos del silencio.

Cuando alguien dice "tiremos código", lo primero que pienso ya no es "dale". Pienso: "¿es realmente necesario?". No por pereza — por respeto al código que ya está funcionando.

La tentación del refactor.

Todo desarrollador senior tiene un cementerio de refactors abandonados. Los míos ocupan tres ramas muertas, con mensajes de commit que empiezan con "por fin limpié..." y terminan sin mergearse.

"Un código que funciona, aunque sea feo, vale más que diez elegantes que nunca se terminan."

No es que estemos en contra de mejorar. Estamos en contra de mejorar sin necesidad. La diferencia está en la pregunta que hacemos antes:

!
Regla de los tres dolores: si un bloque de código no nos duele tres veces, no lo tocamos. Una vez es mala suerte, dos es casualidad, tres es patrón.

Cuando sí escribimos.

Lo que sí priorizamos:

// Reglas para decidir si vale la pena
const vale = (cambio) => {
  return
    cambio.resuelveDolorReal      // no teórico
    && cambio.cabeEnUnPR         // no en cinco
    && cambio.noRompeContratos   // con otros equipos
    && hayTests();             // siempre
};

El resto queda en el backlog. Y a veces, meses después, nos damos cuenta que el "problema" dejó de existir por otra razón.

El costo del no.

No escribir código tiene costo también. Alguien tiene que defender la decisión, explicarla, documentarla. Tenemos un doc interno que se llama "Cosas que decidimos no hacer" — 38 entradas. Cada una con fecha, razón, y la persona que propuso no hacerlo.

Ese doc es, probablemente, la herramienta más importante que construimos en 2025.