PD:Esta edición es siguiendo los consejos de un amigo. Hoy Manolo es quien me riñe.
Martes. 09:15. Entro YO en el despacho de Manolo con paso de evangelista. MacBook bajo el brazo. Tres pestañas de diagramas de arquitectura abiertas. Y esa expresión de quien acaba de salvar a un gatito de las fauces de un Bull dog.
—Manolo, misión cumplida. He convencido a los de Nexova para que paren y rehagan la arquitectura desde cero.
—¿Parar? ¿Cuánto tiempo?
—Seis meses. Quizá siete. Pero cuando terminen van a tener una base sólida. Microservicios bien desacoplados, API gateway, event sourcing, testing al 90%. Una catedral, Manolo. Una catedral.
Manolo me mira. Deja el café. Se recuesta en la silla. Y hace algo que no esperaba:
—¿Cuántos usuarios tienen?
—Unos tres mil. Pero eso no es lo relevante, lo relevante es que...
—¿Y cuántos tendrán dentro de siete meses con el producto parado?
Silencio.
—Jose, ¿cuántos van a tener?
—Los mismos, pero con una plataforma que escala...
—¿Escala a qué? ¿A los tres mil que ya no recuerdan por qué se registraron?
No esperaba esto de Manolo. Manolo, el de los contratos exclusivos. El del foso que se evapora. El que viene a que yo le explique las cosas.
Pero Manolo lleva meses leyendo. Y lo que dice a continuación me desarma.
—Jose, ¿tú conoces a Herbert Simon?
Lo miro como quien ve a su perro abrir el frigorífico.
—Premio Nobel, 1978. Racionalidad limitada. ¿Te suena?
—Claro que me NO me suena, Manolo.
—Entonces no sabrás que Simon demostró que en entornos complejos con información incompleta, buscar la solución óptima es irracional. Lo racional es satisfacer: encontrar una solución suficientemente buena y actuar. Satisficing, lo llamó.
Pausa.
—Tu catedral de microservicios es una búsqueda del óptimo global en un paisaje que no conoces. No sabes si Nexova necesita escalar a cien mil usuarios o pivotar a otro segmento. No sabes si su modelo de negocio sobrevive seis meses más. No sabes si la feature que no están lanzando es la que hubiera cambiado la curva.
—Pero Manolo, si la arquitectura no aguanta...
—¿Aguantar qué? ¿La carga de tres mil usuarios? Jose, estás construyendo un puente para un tráfico que no existe. Y mientras tanto, la carretera se está moviendo.
Stuart Kauffman estudió los paisajes de aptitud en sistemas complejos. En un paisaje rugoso —lleno de picos y valles— los organismos que dan pasos pequeños y rápidos exploran más terreno que los que intentan calcular la ruta perfecta al pico más alto. Porque el pico más alto de hoy puede ser un valle mañana.
El mercado de una startup es un paisaje rugoso. Cada feature lanzada es un paso. Cada interacción con el usuario es información. Cada pivote es adaptación.
Seis meses sin pasos no es estabilidad. Es ceguera.
—Jose, ¿tú sabes cuánto dura el código hoy?
—¿A qué te refieres?
—La vida media. El half-life. ¿Cuánto tiempo sobrevive una línea de código antes de ser reescrita, refactorizada o eliminada?
No contesto, porque sé adónde va.
—En 2015 los estudios decían que entre dieciocho meses y dos años. En 2023, con los frameworks cambiando cada trimestre, bajó a meses. Y ahora, con la IA generando y reescribiendo código... Jose, estás embalsamando algo que tiene la esperanza de vida de una mosca.
Manolo se levanta. Se sirve más café. Y sigue.
—Tú me enseñaste lo de Clausius. La entropía. Los sistemas cerrados. Me dijiste que mi foso se evaporaba porque no importaba energía nueva. ¿Y qué estás haciendo tú con Nexova? Cerrarles el sistema. Siete meses sin input del mercado. Sin feedback. Sin fricción creativa. ¿No era eso exactamente lo que me criticabas a mí?
Touché.
John Boyd, coronel de la Fuerza Aérea estadounidense, desarrolló el concepto del bucle OODA: Observar, Orientar, Decidir, Actuar. Boyd no decía que gana el que tiene mejor plan. Decía que gana el que hace cliclos más rápido. El que observa antes, orienta antes, decide antes, actúa antes.
Cada ciclo OODA es una oportunidad de aprendizaje. Cada feature lanzada es un ciclo. Cada release es una observación.
Siete meses de refactoring son siete meses con el bucle OODA congelado. No estás mejorando el avión. Le estás quitando los instrumentos de vuelo para repintarlo.
—Pero Manolo, el código legacy es deuda técnica. Y la deuda técnica mata empresas.
—¿Sabes qué mata más empresas que la deuda técnica? La irrelevancia. Llegar tarde. Tener un producto perfecto que nadie quiere. Eso no es deuda técnica, Jose. Es quiebra de mercado. Y de esa no se refactoriza nadie.
Manolo abre su portátil. Me muestra una gráfica. Nexova tiene tres competidores. Dos de ellos, con código que probablemente haría llorar a cualquier ingeniero de software, han triplicado usuarios en el último trimestre.
—¿Sabes qué tiene su código, Jose? Usuarios. ¿Sabes qué tiene la catedral de Nexova? Diagramas.
¡Y sino que se lo digan a @levelsio que tiene un index.php de 50 mil lineas!
Leigh Van Valen propuso en 1973 la hipótesis de la Reina Roja, tomada de Alicia a Través del Espejo: "Hace falta correr todo lo que puedas para permanecer en el mismo sitio." En biología evolutiva, las especies no compiten contra un estándar absoluto. Compiten contra otras especies que también están evolucionando.
Mientras Nexova reescribe su arquitectura, sus competidores no están esperando. Están lanzando. Están aprendiendo. Están iterando. Cada día que Nexova pule su catedral, el mercado se mueve. Y cuando salgan, dentro de siete meses, con su arquitectura perfecta y su coverage al 90%, el mercado al que apuntaban ya no estará ahí.
Habrá evolucionado. Y ellos seguirán adaptados a un ecosistema que ya no existe.
—Jose, una pregunta. Con la IA actual, ¿cuánto cuesta reescribir un módulo completo?
—Depende del módulo, pero...
—Horas. A veces minutos. Y me estás diciendo que vale la pena parar siete meses para escribir código perfecto cuando cualquier modelo de lenguaje puede reescribir un servicio entero en una tarde.
—No es lo mismo, Manolo. La IA no entiende el contexto de negocio, no...
—Jose. Tú me dices siempre que el valor no está en el activo sino en la capacidad de generar el activo. ¿Y ahora me dices que el código —el activo más replicable de la historia— es lo que hay que proteger?
Me quedo callado. Porque tiene razón. Y tiene razón usando mis propias palabras.
Frederick Brooks lo escribió en 1975, en The Mythical Man-Month: "Plan to throw one away; you will, anyhow." Planea tirar la primera versión a la basura, porque lo vas a hacer de todos modos.
Eso era verdad en 1975. En 2026, con IA que genera, refactoriza y migra código, la frase debería ser: planea tirarlo todo cada trimestre. Porque puedes. Y porque el mercado te va a exigir que lo hagas.
—Jose, yo no sé de código. No sé qué es un microservicio ni me importa. Pero sé una cosa: llevo treinta años vendiendo. Y ningún cliente me ha comprado nunca una arquitectura. Me compran lo que resuelvo. Y para resolver, hay que estar ahí. No en un laboratorio puliendo la solución perfecta.
—Manolo, pero hay un mínimo de calidad técnica que...
—¿Un mínimo? Claro. Como hay un mínimo de limpieza en un restaurante. Pero el restaurante con la cocina más limpia del mundo y ningún plato en la carta no es un restaurante. Es un quirófano. Y la gente no va a quirófanos a cenar.
Me río. Porque la metáfora es ridícula. Y porque es perfecta.
Manolo no está diciendo que el código no importa. Está diciendo algo más sutil: que la calidad del código es una variable dependiente, no independiente. Depende del estadio de la empresa, del tamaño del mercado, de la velocidad de cambio del entorno, de la disponibilidad de herramientas para reescribir.
Optimizar una variable dependiente como si fuera independiente es un error de modelado. Y los errores de modelado, en sistemas complejos, no se corrigen con más optimización. Se corrigen cambiando el modelo.
—Jose, ¿sabes cuál es la diferencia entre un arquitecto y un constructor?
—Dime.
—Que el arquitecto dibuja la catedral perfecta. Y el constructor te pone un techo antes de que llueva.
Tus clientes se están mojando, Jose. Y tú estás eligiendo el mármol de las columnas.
No contesto. Porque esta vez el que ha venido a aprender soy yo.
Y la lección es esta: en un mundo donde el código es efímero, la arquitectura es fungible y la IA abarata la reescritura hasta casi cero, el único activo que no se deprecia es la velocidad de aprendizaje. El GTM no es un compromiso con la calidad. Es la calidad que importa cuando el terreno se mueve bajo tus pies.
Tu catedral puede ser magnífica, Jose.
Pero si la construyes en el sitio equivocado, solo habrás demostrado que sabes poner piedras muy bonitas en un desierto donde nadie reza.
Gracias por leer hoy... a Manolo.