Regla del 90-90

El primer 90% del código consume el primer 90% del tiempo de desarrollo. El 10% restante consume el otro 90%.

(Sí, suma 180%. Ese es exactamente el chiste — y la lección.)

Origen

La formuló Tom Cargill, ingeniero de Bell Labs, y fue Jon Bentley quien la publicó en su columna Programming Pearls de la revista Communications of the ACM en septiembre de 1985. Cargill la decía como observación operativa después de años viendo proyectos de C++ y telefonía: el sistema “funciona en demo” rápido, pero el último puñado de bugs, casos borde, integraciones, performance y hardening se llevan más tiempo que todo lo anterior.

Ejemplo: el “casi terminado”

Es la ingeniería de software resumida en un aforismo. La feature que está al 90% en el sprint review. “Sólo me falta integrar con producción y manejar el caso del usuario sin email.” Tres sprints después seguís en eso. ¿Por qué?

• El happy path es lineal: tenés un caso, lo escribís, funciona.
• Los casos borde son combinatorios: timeouts, charset distinto, usuario eliminado a mitad de la operación, race conditions, retries idempotentes, observabilidad, telemetría, alertas, logs útiles, documentación, runbook, training del equipo de soporte.

Cada uno parece “5 minutos”. Pero son veinte cosas de cinco minutos cada una, en serie, con context-switch, en un equipo donde alguien además está de vacaciones.

El uso operativo es dejar de mentirse en las estimaciones. Cuando alguien dice “está al 90%”, el manager bueno ya no escucha “queda poco” — escucha “queda otro tanto que lo que ya hicimos”. Las dailies dejan de discutir features y empiezan a discutir cuáles de esos diez “5 minutos” son realmente bloqueantes.