Optimiza para el tercer año: por qué la mayoría del software latinoamericano muere en el segundo

La mayoría del software se optimiza para la demo. El estudio optimiza para el tercer año — el momento en que un equipo real depende del sistema a las 11pm de un martes, mucho después de que quienes lo construyeron se fueron. Eso no es un eslogan; es una lista de verificación, y casi nada de ella es visible en la demo que gana el contrato.

El precipicio del segundo año

El primer año todo está fresco: el desarrollador recuerda cada decisión, los datos están limpios, el alcance es pequeño. El segundo año las cosas se desvían — un nuevo requerimiento aquí, un parche sin documentar allá, una dependencia que hay que actualizar. El tercer año es la prueba: el desarrollador original ya no está, la memoria institucional se fue con él, y el sistema o se sostiene solo o se convierte en eso que nadie se atreve a tocar. En Latinoamérica en particular — donde los presupuestos son ajustados y la continuidad es rara — el precipicio del segundo año es donde muere en silencio la mayoría del software público y comercial.

Por qué sucede

Rara vez es una gran falla. Es la acumulación de pequeñas omisiones, cada una de las cuales fue racional saltarse bajo presión de tiempo:

• ⟂El conocimiento vive en la cabeza de una persona, no en un runbook.
• ⟂No hay procedimiento de recuperación, así que la primera caída real es una improvisación.
• ⟂El alcance cambió una docena de veces y nada de eso quedó por escrito.
• ⟂La tubería de datos fue una limpieza única, así que la siguiente publicación de datos la rompe.
• ⟂La dependencia ingeniosa y exótica ahora no tiene mantenimiento y nadie la entiende.

Qué significa realmente "optimizado para el tercer año"

La solución no es heroísmo. Es disciplina aplicada el primer día, cuando es más barata y menos urgente:

• ⟂Alcance escrito antes del código — qué se construirá, qué no, cómo se prueba.
• ⟂Un runbook, un procedimiento de recuperación y un registro de cambios entregados con cada sistema.
• ⟂Modelos de datos canónicos, para que la siguiente publicación sea un insumo, no un proyecto.
• ⟂Tecnología aburrida y bien entendida por encima de la astucia ingeniosa y frágil.
• ⟂Documentación escrita para el equipo que hereda el sistema, no para el que lo construyó.

Cualquiera puede construir software que sobreviva la demo. La disciplina es construir software que sobreviva a quienes lo construyeron.

La prueba

Esta es la única prueba de aceptación que importa: son las 11pm de un martes, la persona que construyó el sistema está ilocalizable, y algo salió mal. ¿Puede el equipo de guardia entender qué está pasando, encontrar el procedimiento de recuperación y arreglarlo sin ti? Si sí, construiste infraestructura. Si no, construiste una demo que casualmente se lanzó. Cada decisión en este estudio se toma pensando en ese martes por la noche — que es exactamente por qué el trabajo se documenta, el alcance se escribe y las tuberías de datos se construyen para absorber la próxima publicación en lugar de romperse con ella.