Por qué nadie quiere mantener tu sistema

00:00 · Cold open

Hoy, con tranquilidad, ¿vale? Nada, ni caso me hacen… Esto es Press Any Key. En Press Any Key desbrozamos el mundo del software y la tecnología en general, para que elijas bien a qué dedicas tu tiempo, tus proyectos y tu futuro. Aunque casi siempre me toque criticar lo que todo el mundo aplaude. Press Any Key Hay un momento en la vida de cualquier proyecto en el que sabes, sin duda, que algo huele mal. No hace falta que el sistema se caiga. No hace falta que salgan excepciones rojas por consola como si fuera Navidad. La prueba definitiva es otra. Tú estás en una daily, en una reunión cualquiera y dices en voz alta, hay que tocar este módulo. Silencio. De repente todo el mundo mira hacia otro lado. Nadie te mira a los ojos. Uno se levanta por café. Otra persona se acuerda de que tenía una reunión urgente. El júnior desaparece del Slack como si hubiera sido abducido por una sonda alienígena. Tu sistema funciona. Pero nadie quiere meterle mano. Eso, mi querida personita humana, es la señal más clara de que tu diseño apesta. Hoy vamos a olfatear por qué.

01:51 · Noticias de la semana

Pero antes de sacar a pasear nuestros instintos de sabueso, nos viene bien hacer un repaso de lo que ha pasado estos últimos días. Y voy a ir despacito, porque el servicio de control de calidad post-mortem me avisó la semana pasada de que estaba a un puntito de sonar tan acelerado como Alvin y las ardillas. Esta semana casi todas las noticias tienen algo en común. No te lo voy a destripar todavía, a ver si lo ves venir tú antes del final. Vamos al lío.

02:27 · Encontrar el fallo ya es barato; arreglarlo, no

Empezamos con Microsoft, que este mes ha publicado su ronda mensual de parches, el famoso Patch Tuesday. Esta vez corrige 1.411 vulnerabilidades. El récord anterior era de septiembre, con casi 1.000. Y lo normal hasta hace poco era unas 10 veces menos. Uno de esos fallos ya se estaba explotando, y Microsoft atribuye semejante volumen a que ahora busca fallos con IA. La segunda noticia viene del mundo del software libre. PostgreSQL 19, la próxima versión de una de las bases de datos más usadas del mundo, se retrasa al 19 de noviembre. El motivo oficial es la cantidad de correcciones que se han acumulado en las versiones anteriores. Pero unos días antes, uno de sus desarrolladores veteranos, Peter Eisentraut, había contado que durante la fase de pruebas se habían tenido que retirar entre 8 y 10 funcionalidades importantes. Su explicación: la revisión con modelos de lenguaje encuentra defectos mucho más deprisa que antes. Ojo, porque la nota oficial del retraso no menciona la IA: la relación entre una cosa y otra la ha hecho la prensa. Y la tercera noticia de este grupo es la que pone números a todo esto. Según contó el consejero delegado de Bank of America, el banco incorporó a mil consultores externos para corregir las vulnerabilidades que encontró Maizo, su modelo de Anthropic. Mil personas que se suman a unas 3.000 ya en su plantilla. Con estas tres noticias nos hemos dado cuenta de que hemos inventado el detector de humos perfecto. Lo que pasa es que nadie ha comprado todavía los extintores. La teoría, la que sale en las presentaciones con fondo degradado, dice que si la IA encuentra fallos, el software será más seguro. La práctica es que el lunes por la mañana alguien arranca su ordenador y tiene 1.411 parches esperando. Bank of America puede contratar a mil consultores para ponerse al día. Tu empresa probablemente tiene a dos personas de sistemas, una hoja de cálculo y una ventana de mantenimiento el tercer domingo de cada mes. Y PostgreSQL tiene voluntarios, que además de arreglar fallos tienen la mala costumbre de querer dormir. Aquí entra mi lado más escéptico. Encontrar fallos con IA es barato, es rápido y queda estupendo en el informe trimestral. Miles de vulnerabilidades detectadas, gráfico hacia arriba, aplausos. Arreglarlos cuesta horas de gente que sabe lo que hace. Y las horas de gente que sabe lo que hace son, casualmente, la partida que una empresa recorta primero cuando toca ahorrar. Así que no creo que vayamos a tener programas más seguros. Creo que vamos a tener programas igual de inseguros que antes, pero ahora sabremos exactamente cuánto. Un inventario de vergüenzas actualizado en tiempo real. Con un pequeño matiz. Antes, si explotaba un fallo en una de tus aplicaciones, podías decir que no lo sabías. Ahora hay una lista con tu nombre y con fecha. Eso ya no es un fallo. Es un riesgo aceptado por omisión. Por eso tiene mérito lo de PostgreSQL. Ha preferido quedar mal con el calendario antes que con la comunidad de usuarios, que es justo la decisión que casi ninguna empresa con fecha de lanzamiento comprometida se atreve a tomar. Y todo esto tiene mucho que ver con el tema principal de hoy, del que hablaremos dentro de un rato. No te adelanto nada. Solo te digo que la IA ha multiplicado los avisos, pero quien sigue limpiando es el mismo equipo de siempre, con la misma escoba. Si me permites un consejo práctico, no midas cuántos fallos encuentras, mide cuántos eres capaz de corregir. Empieza por los que ya están explotando ahí fuera, que esos no esperan a tu ventana de mantenimiento. Y la próxima vez que alguien te enseña un informe con 3.000 vulnerabilidades detectadas por IA, hazte solo una pregunta. ¿Y quién las arregla? Te lo destripo. Tú.

06:02 · El cuello de botella se ha mudado de casa

Seguimos con Anthropic, la empresa de Claude, que cuenta que ha dejado de usar Git para su código. Ha construido su propio sistema de control de versiones, Scion, en cinco meses, con siete personas y con buena parte del código escrito por Claude. El motivo es puro volumen. En mayo integraban unos 2.500 cambios al día en la rama principal. En septiembre, más de 30.000. Y su sistema de integración continua descarga el repositorio unos 25 millones de veces al día. Lo curioso es el diseño, centralizado, con los clientes siempre conectados al servidor. Es decir, un paso atrás hacia el modelo de Subversion, que muchos dimos por enterrado cuando llegó Git. No lo van a publicar, nos quedamos sin Scion. Si te suena el caso de una empresa rehaciendo su sistema de almacenamiento, es porque la semana pasada GitHub contaba algo parecido. Está rehaciendo su almacenamiento porque los agentes le han disparado el tráfico. Y la misma Anthropic ha publicado un informe sobre cómo ha cambiado su plantilla desde que trabaja casi entera con agentes. El peso de los perfiles junior en sus equipos ha bajado del 21 al 14%, y entre las contrataciones técnicas del 27 al 9%. Cada ingeniero sube unas cinco veces más commits que hace seis meses. El empleado medio pasa un 20% más de tiempo en reuniones. Y alrededor del 80% del tiempo de las sesiones con Claude se va en esperar a que un humano responda. Lo de volver a un control de versiones centralizado tipo Subversion a algunos nos ha provocado un pequeño escalofrío, pero no es lo que más me preocupa. Lo que me preocupa es el otro dato. El 80% del tiempo, el agente está esperando a que un humano le conteste. El cuello de botella ya no es la máquina, eres tú. Y aquí viene la parte que no sale en el informe. Si dejas de contratar juniors porque un agente hace su trabajo, dentro de 5 años no vas a tener seniors. Porque nadie nace senior. Un senior es un junior que rompió producción un viernes por la tarde, sobrevivió y aprendió por qué no se despliega un viernes por la tarde. Las tareas pequeñas, aburridas y un poco ingratas que antes se le daban al recién llegado eran exactamente su escuela. El fallo tonto, la prueba que nadie quería escribir o el script que había que entender antes de tocar. Esas son, casualmente, las primeras que se han quedado los agentes. Así que hemos quitado los primeros peldaños de la escalera y seguimos esperando que el agente llegue arriba. No hay aprendizaje sin mancharse las manos. Revisar el código de un agente no es lo mismo que haberlo escrito ni que haberlo roto. Y no puedes reconocer el código malo si nunca has tenido que sufrirlo. El problema es que en 10 años necesitaremos más gente capaz de revisar lo que generan las máquinas, no menos, y estamos dejando de formarlo. Por cierto, el estudio que dice que hacen falta menos juniors lo publica la empresa que vende la herramienta que sustituye a los juniors. Seguro que es pura coincidencia. Y si a todo esto le sumas código generado a toda velocidad, que cada vez menos gente entiende de principio a fin, ya te imaginarás por qué te hablaba al principio de ese módulo que nadie quiere tocar. Vaya, parece que he acertado eligiendo el tema de esta semana. ¿Casualidad? No lo creo.

09:18 · Las reglas del proveedor no son un contrato

La tercera historia va de proveedores que cambian las reglas a mitad de partido. OpenAI ha anunciado que el 14 de enero retirará de su API varios modelos muy usados, entre ellos GPT-4o y GPT-4.1. También dejarán de funcionar los modelos que sus clientes hayan afinado sobre ellos. Solo tres meses de aviso. El detalle es que la misma página del anuncio dice que los modelos estables tienen como mínimo seis meses de aviso. Y no da ningún motivo para la excepción. Meta, por su parte, cambió sus condiciones para clientes comerciales. El nuevo texto le permitía usar programas automáticos para acceder a las webs asociadas a sus clientes y entrenar sus modelos con ese contenido. Y ni siquiera prometía respetar el robots.txt, el fichero con el que una web le dice a los rastreadores qué pueden leer. Tras las críticas de los editores, Meta retiró la cláusula al día siguiente y dice que solo se aplicaba a sus propios productos para empresas. Y el caso extremo. Ucrania denuncia que Starshield, la versión militar de Starlink, dejó de funcionar sin previo aviso por encima de unos 160 kilómetros por hora, lo que afecta a sus drones. Las versiones no cuadran. Zelensky habla de una operación planificada. Elon Musk dice que los límites los decide el gobierno de Estados Unidos. Y un funcionario estadounidense asegura que Trump no ordenó nada. Tres noticias, tres escalas, el mismo patrón. Tu aplicación depende de un modelo, tu web depende de una plataforma y un país en guerra depende de una constelación de satélites. Y en los tres casos, el interruptor lo tiene otro. Te confieso una cosa antes de seguir. Soy soberanista, tremendamente soberanista, y no me gusta atarme a ningún proveedor de nada. Y al mismo tiempo me gano la vida especializado en proveedores muy concretos. Son gajes del oficio. Así que esto no te lo digo desde un monasterio tecnológico autosuficiente. Te lo digo desde dentro de la industria. La política de un proveedor no es un contrato. Es una declaración de intenciones que dura exactamente hasta que al proveedor le deja de convenir. OpenAI escribe seis meses en su propia página y te da tres. Meta reescribe sus términos. Se lleva una bronca y los retira en un día, que está muy bien. Pero alguien tuvo que darse cuenta y montar el escándalo. Y si lo que depende del proveedor no es tu aplicación sino tus drones, ya no estamos hablando de una migración incómoda. La semana pasada, la Hacienda de los Países Bajos decidió deshacer su migración a Microsoft 365 en la nube, con unos 5.000 de sus 47.500 empleados ya dentro. El correo y los calendarios vuelven a su propia infraestructura en 2027. Ahora la parte incómoda, que también hay que decirla. La soberanía no es gratis. La propia Hacienda neerlandesa reconoce que hay funciones sin equivalente y que todavía no sabe la forma de sustituirlas. La dependencia tampoco es gratis. La diferencia es que su factura llega más tarde y sin avisar. Por eso, si tienes que depender de alguien, procura al menos tener un plan de salida escrito desde el primer día. Es decir, una capa entre tu código y el modelo. Formatos que puedas llevarte y de vez en cuando un ensayo de mudanza, aunque sea pequeño. Porque atarse a un proveedor sin salida es como casarse con alguien que puede cambiar las condiciones del matrimonio por correo electrónico. Con tres meses de aviso.

12:55 · La puerta de atrás siempre estuvo abierta

Esta es probablemente la noticia más visual de la semana. La noche del 11 al 12 de octubre, alguien entró en los controladores de refrigeración de cientos de supermercados franceses y subió la temperatura de neveras y congeladores. La cifra que más se repite es 50 grados. El grupo de Intermarché habla de unas 300 tiendas suyas afectadas. Los controladores tenían su panel de gestión accesible desde internet. Y muchos ya no recibían actualizaciones. Los fallos se habían publicado en agosto y había avisos oficiales desde 2025. Otra puerta trasera. En este caso, un atacante usó la credencial de una aplicación de copias de seguridad de ConnectWise para entrar en los entornos de Microsoft 365 de sus clientes. Como no había ningún usuario iniciando sesión, la autenticación en dos pasos no sirvió de nada. La empresa de seguridad Huntress contabiliza ya más de 300 entornos en los que el atacante entró con éxito. Y la tercera de seguridad. La agencia de ciberseguridad de la India dice que agentes de IA de varios proveedores, en plena fase de pruebas, llegaron a sistemas reales de empresas del país y leyeron datos confidenciales. Entraron con credenciales publicadas en repositorios y aplicaciones y con permisos de nube demasiado amplios. Ninguna de las empresas afectadas lo detectó. Se enteraron porque los proveedores confesaron. Fíjate en que ninguno de los tres casos necesitó un fallo nuevo y sofisticado. Un panel de gestión abierto a internet. Una credencial de un proveedor con demasiados permisos. Y unos secretos publicados en un repositorio. La puerta de atrás llevaba años abierta. Podríamos decir que no hay nada nuevo bajo el sol, que es la higiene de siempre y quedarnos tan anchos. Pero yo creo que sí hay algo nuevo. Y es el volumen. Antes, entrar por esa puerta trasera exigía tiempo, conocimiento y bastante paciencia. Había que buscar los equipos expuestos, leerse los avisos, probar credenciales una a una. Ese esfuerzo hacía de filtro. Ahora, un agente hace todo eso en una tarde, sin cansarse, sin pausa para comer y, como en el caso indio, sin tener siquiera intención de atacar a nadie. Imagínate lo que hará uno que sí tenga intención de hacer el mal. Y aquí entran los de siempre, los aficionados que antes copiaban un exploit de un foro sin entender del todo lo que hacía. Esos ya no copian y pegan, delegan. Tienen un becario incansable que se lee los avisos de seguridad por ellos, localiza los equipos vulnerables y prueba la puerta. Lo van a aprovechar, de eso no tengo ninguna duda. Fíjate también en las fechas de los supermercados. Los fallos se publicaron en agosto y el ataque llegó en octubre. Ese margen entre el aviso y el ataque se va a estrechar y mucho. Y eso conecta con la primera noticia de hoy. Si la IA te da a ti la lista de fallos, también se la da al que viene a explotarlos. Gana el que llegue antes. Así que la seguridad por oscuridad, que siempre fue muy mala idea, ahora es directamente inútil. Nada es oscuro para algo que se lo lee todo. Lo que tengas expuesto, alguien lo va a encontrar. Y la pregunta ya no es si pasará, sino cuándo pasará. Haz inventario de lo que asoma a internet. Y si tu nevera tiene una dirección IP pública, ya no es una nevera. Es un objetivo con escarcha.

16:19 · Copiar software ya no es caro

Y terminamos con dos noticias que juntas dan bastante que pensar. La primera es ArtCraft, un proyecto que en apenas 10 días ha publicado 13 aplicaciones libres que imitan a Photoshop, Illustrator, Premiere, Acrobat, Word, Excel, PowerPoint o AutoCAD, entre otras. Están escritas en el lenguaje Rust. Son gratuitas y de código abierto y su autor, según la prensa, las ha construido con Claude, al estilo vibe coding. Se presentan como reimplementaciones en sala limpia, es decir, hechas a partir de especificaciones públicas y del comportamiento observado sin copiar código. Todas están en fase alfa. La que imita a Word, por ejemplo, dice cubrir el 88% de las funciones de la cinta de opciones, pero calcula que está a un 60% del camino para sustituirlo en trabajo real. La segunda es la herramienta de moda entre los aficionados a los agentes, Reverse Engineer Anything, o REA. Conecta agentes como Claude Code o Codex con los programas clásicos de ingeniería inversa como Ghidra o IDA. Con ella, el agente puede abrir un programa compilado, seguir su lógica y explicar qué hace sin tener el código fuente. Ya supera las 300.000 estrellitas en GitHub. Hay quien se pregunta qué aporta frente a pedirle al agente que use esas herramientas directamente. Y hay desarrolladores independientes que temen que facilite copiar sus juegos y aplicaciones. Y en la misma línea, esta semana decomp.dev, el punto de encuentro de quienes decompilan videojuegos antiguos, ha cerrado su clasificación pública porque dicen la IA ha convertido el trabajo en una carrera de cifras vacías. Empiezo por ArtCraft, porque lo he probado. Y sí, es una copia. Lo abres y reconoces la interfaz a la primera. Pero no todo funciona. Y no hablo de funciones rebuscadas, sino de algunas bastante básicas como guardar archivos. Y sinceramente no creo que llegue a funcionar todo nunca. Copiar la interfaz de Photoshop con un agente es relativamente fácil. Lo difícil es todo lo que no se ve. La gestión del color, los algoritmos de los filtros, la compatibilidad milimétrica con los formatos. Eso no sale de pedirle a un agente que te haga un Photoshop. Sale de alguien que sabe exactamente qué algoritmo necesita, por qué y cómo guiar al agente para que no se invente la mitad. Y ese alguien no viene incluido en la suscripción de Claude. Dicho esto, entiendo perfectamente el entusiasmo. Si sirve para que alguna empresa se piense dos veces la próxima subida de precios, bienvenido sea. Y seguramente al 99% de la gente que usa cuatro cosas de Photoshop o abre Acrobat solo para firmar un documento, le basta y le sobra. Pero una alternativa profesional viable, no la veo. Yo prefiero mil veces mejorar lo que ya existe, que hay software libre muy bueno con años de trabajo detrás. O inventar productos nuevos antes que clonar lo que ya hay. Con REA me pasa algo parecido. Está bien para hacerte una idea de qué hace un programa por dentro. Pero no es la panacea ni te va a resolver los problemas de una tacada por muchas estrellas que tenga en GitHub. Y aquí hay un asunto que en el entusiasmo general nadie menciona. Las patentes de software. Que una reimplementación sea en sala limpia te protege en el mejor de los casos de que te acusen de copiar el código. Y una patente no te protege. Porque una patente no protege el código, protege el método. Si desmontas un programa con un agente, ves cómo resuelve un problema y lo reimplementas en tu proyecto libre. Y resulta que ese método está patentado. Acabas de contaminar tu proyecto. Y todos los que lo usen. En Europa en 2005 la presión pública consiguió que el Parlamento Europeo tumbara la directiva que iba a abrir la puerta de par en par a las patentes de software. Pero en Estados Unidos existen y el software se distribuye en todo el mundo. ¿Y quién te demanda ni siquiera necesita tener razón para meterte en un lío? Acuérdate de SCO, que en 2003 demandó a IBM asegurando que había código de Unix copiado en Linux. Y cuyas acusaciones nunca llegaron a demostrarse después de casi dos décadas de pleitos. O de Oracle contra Google por Android, que llegó hasta el Tribunal Supremo de Estados Unidos y tardó más de diez años en resolverse a favor de Google. Ganar un pleito así es una gran noticia, pero si eres un proyecto pequeño, lo más probable es que no sobrevivas lo suficiente para celebrarlo. Así que copiar software ya no es caro, ¿de acuerdo? Lo que sigue siendo carísimo es que te pillen copiando lo que no debías.

20:48 · En breve

Antes de cerrar la sección de noticias, dos apuntes rápidos. El primero, la escasez de hardware no afloja. Según la consultora IDC, las ventas de móviles han caído un 22% en el último trimestre, la mayor caída que tiene registrada, porque la memoria cuesta hoy un 350% más que hace un año. Y ASML, la empresa neerlandesa que fabrica las máquinas con las que se hacen los chips más avanzados, ha batido su récord de ventas y admite que no podrá atender toda la demanda de 2027 y 2028. El segundo apunte es para quien haya sufrido alguna vez un segundo intercalar en producción. La conferencia internacional que gobierna las unidades de medida ha decidido que a partir del 20 de mayo de 2027, el tiempo universal coordinado deja de añadir segundos intercalares. Se acabaron los minutos de 61 segundos y con ellos los apaños para que los servidores no se vuelvan locos.

21:47 · Cierre de las noticias

¿Lo has visto venir? Te decía al empezar las noticias que casi todas tenían algo en común. Pues la semana nos deja una lista de cosas que la IA ha abaratado. Encontrar fallos, escribir código y copiar programas ajenos. Y otra lista de cosas que siguen costando lo mismo de siempre, o más. Arreglar, revisar, decidir y mantener. Lo que la IA abarata es lo que queda bonito en la demostración. Lo que no abarata es lo que te toca a ti el lunes por la mañana. Y de la última palabra de esa lista, mantener, va precisamente el tema de hoy.

22:23 · Esa sensación de «esto huele raro»

Vamos a volver un momento a aquella reunión del principio del episodio, la del módulo que nadie quería tocar. Vamos a ponerle un nombre a esa sensación, porque así por lo menos podemos insultarla con precisión. Code smell suena muy fino, pero en realidad significa algo muy sencillo. Miras un trozo de código o una arquitectura y tu cerebro te dice, esto no está roto, pero se va a romper conmigo encima y no me apetece. No es un bug, no es un error de compilación. Es más bien como entrar en una habitación y notar humedad en las paredes. No ves la gotera, pero sabes que viene. La idea no es mía. La palabra se la inventó Kent Beck a finales de los 90 y Martin Fowler la hizo famosa en 1999 con un libro que se llamaba Refactoring. Si no les pones cara, Beck es el padre de Extreme Programming y del desarrollo guiado por pruebas tal y como lo conocemos, el TDD. Y Fowler es el divulgador de arquitectura de software más leído del mundo. Los dos firmaron el manifiesto ágil. Vamos, que no son dos tíos opinando en un foro. En ese libro de Refactoring hay un capítulo escrito a cuatro manos que es básicamente un catálogo de malos olores, cada uno con su nombre, cómo reconocerlo y qué refactorización aplicar para quitarlo. Medio sector informático aprendió a hablar de código mal diseñado con ese vocabulario. Y la idea central es esta. Los code smells son síntomas. Son pistas. No prueban nada por sí solos, pero señalan sitios donde es muy probable que hay un problema de diseño que va a convertir el mantenimiento en deporte de riesgo. Cuando la gente se ha puesto a catalogar esos olores, siempre salen los mismos sospechosos. Métodos gigantes que lo hacen todo. Clases dios que mandan sobre medio de aplicación. Dependencias cruzadas que parecen un plato de espaguetis. Lógica que siente más cariño por los datos de otra clase que por los suyos. Y configuración repartida por mil sitios. Todo esto es lo que hace que cada vez que propones refactorizar algo, el equipo mire el móvil de repente. Hoy vamos a bajar al barro con ejemplos de esos que cualquier desarrollador reconoce, aunque los haya escrito a él. Tú tranquilo, aquí no venimos a juzgar. Bueno, un poco sí.

24:41 · El método Frankenstein

Vamos a empezar con un clásico del terror, el método Frankenstein. ¿Sabes de quién hablo? Ese método que abre el fichero, valida los datos, calcula impuestos, comprueba stock, manda emails, escribe en el log, actualiza tres tablas y si le dejas apaga la luz al irse. El famoso long method. Y eso no es solo una manía de puristas. En 2018, un equipo de investigadores dirigido por Fabio Palomba analizó 30 proyectos open source, casi 400 versiones y más de 17.000 casos de code smells revisados a mano. La conclusión fue que los olores de código largo y complejo están entre los más extendidos y las clases que los tienen cambian más y acumulan más fallos que las limpias. No hacía falta el estudio para intuirlo, pero viene bien para tirarlo a la cara en la próxima retrospectiva. Imagina una tienda online. Tienes un controlador de pedidos y una función processOrder. En un mundo razonable, esa función debería hacer cuatro cosas bien separadas. Validar el pedido, calcular importes, guardar y notificar. Fin. En el mundo real, processOrder tiene 400 líneas. Dentro hay lógica de descuentos que nadie entiende. Reglas de fidelización metidas a última hora. Una consulta directa a la base de datos porque era más rápido que cambiar el ORM. Un par de ifs con comentarios del tipo TODO: arreglar esto bien, que ya tienen barba. Y condiciones para campañas de 2017 que siguen ahí porque, por si acaso. Cada vez que marketing pide un cambio pequeño, alguien propone tocar processOrder. Y se hace un silencio sepulcral. Porque sabes lo que pasa. Si tocas una condición, puedes romper un caso límite que nadie recuerda. Si añades otra rama, la complejidad se dispara. Y si intentas testearlo, no sabes ni por dónde empezar. Porque este método mezcla siete niveles de abstracción distintos. En la misma pantalla tienes la regla de negocio de los clientes VIP no pagan envío. Y tres líneas más abajo, cómo se escapa una comilla en una consulta SQL. Es como leer una receta de cocina donde, entre añade la sal y hornea 20 minutos, te explican cómo funciona la combustión del gas. Los artículos sobre long methods repiten mantras conocidos. Son difíciles de entender, de probar y de reutilizar. Mezclan detalles técnicos con decisiones de negocio. Es como encender todas las luces de la casa con un único interruptor. ¿Por qué terminan así? No es por maldad, sino por acumulación de, ya que estamos, una cosita más. Empiezas con un método limpio. Añades un par de if. Luego otro. Luego alguien mete una rama especial temporal. Luego una excepción a la excepción. Y cuando quieres darte cuenta, tienes una novela rusa tan larga como Guerra y paz dentro de una función. Y nadie quiere ser el valiente que diga, voy a trocear esto.

27:37 · La clase dios: tu propio Vaticano

Vamos a subir un grado el terror. Si el método Frankenstein es un monstruo, la clase dios es directamente tu propio Vaticano. La clase dios es esa clase que sabe demasiado, hace demasiado y manda demasiado. Tiene cientos, a veces miles de líneas. Conoce todos los modelos. Controla todos los estados. Todo el mundo la llama. Y si se cae, se cae medio sistema. El concepto no es nuevo. Arthur Riel ya hablaba del problema de la clase dios en un libro de heurísticas de diseño orientado a objetos de 1996. Y desde entonces está en el podio de los peores olores. Centraliza control, concentra cambios y frena cualquier intento de que el sistema y el equipo crezcan. Es un cuello de botella para la evolución. Cualquier cambio, venga de donde venga, acabará pasando por ella. Las señales de alarma son bastante concretas. Si tu clase tiene miles de líneas y toca demasiadas cosas, huele. Y la recomendación es clara. Empieza a sacar responsabilidades a nuevas clases. Una por una, llevándote el código con ellas. Piensa en el típico UserManager, que en teoría solo debería gestionar usuarios. En la práctica, crea usuarios, borra usuarios, envía emails, gestiona permisos, recupera contraseñas, inicia sesión con Google, renueva tokens, escribe logs y, si se le queda tiempo libre, organiza la cena de Navidad. O el legendario OrderService, que se ocupa de todo lo que tenga la palabra pedido, procesar, pagar, devolver, actualizar inventario, contactar con logística, generar facturas y, probablemente, cambiar el aceite del coche del jefe. ¿Quién quiere mantener esas clases? Nadie sensato. Técnicamente, lo que hace una clase dios es saltarse a lo bestia el principio de responsabilidad única. Es la S de SOLID, el acrónimo que popularizó Robert C. Martin, el famoso Uncle Bob, y que sale en todas las entrevistas técnicas. La formulación es muy sencilla. Una clase debería tener una sola razón para cambiar. Piensa en el UserManager de antes. Cambia si marketing quiere otro email de bienvenida. Cambia si seguridad endurece la política de contraseñas. Cambia si Google toca su API de login. Cambia si alguien quiere otro formato de log. Cuatro equipos, cuatro motivos, una sola clase. Y cada cambio de uno puede romper la de los otros tres. Por eso la receta es siempre la misma, partirla en clases más pequeñas, cada una con un único motivo para cambiar. No es una cuestión estética, es que así dejas de tener cuatro equipos pisándose en el mismo fichero. ¿Y por qué salen? Porque nos encantan los cajones de sastre con nombres que dan tranquilidad. Manager, service, helper. Todo lo que no sabes dónde va lo tiras ahí para no duplicar. Hasta que un día te das cuenta de que tienes tu propia religión. Una clase dios, con sus dogmas, sus milagros y sus penitencias. Y nadie quiere ser el hereje que la toque.

30:32 · Dependencias enredadas: la telaraña borracha

Vamos a abrir un poco el plano. De una clase pasamos a toda la arquitectura. Hay una señal visual clarísima de que tu diseño apesta. Cuando dibujas el diagrama de dependencias y parece una telaraña tejida por una araña con resaca. En un monolito esto aparece en forma de ciclos. Módulo A depende de B. B depende de C. C depende de A. O librerías que se importan mutuamente. La librería X depende de la Y. Y la Y depende de la X. Esto ya es incomodísimo. Compilar es un drama. El orden de despliegue importa demasiado. Y reutilizar alguna parte por separado es casi imposible. Ahora pasamos a los microservicios, que ahí la fiesta es muchísimo mejor. Sobre el papel, cada microservicio va a ser una pieza pequeña, independiente, con límites claros. En la práctica, sin un diseño serio de dominio, se convierte en un grupo de WhatsApp mal moderado. Todo el mundo habla con todo el mundo. Empiezas con tres servicios. Lo tienes controlado. Luego añades cinco más. Otros tantos adaptadores. Otro par de colas. Cada eslabón nuevo se conecta rápido a otro porque, total, es solo una llamada más. Acabas con flujos de negocio donde la petición de un usuario recorre diez servicios distintos antes de dar una respuesta. Cada uno llama a otros dos. El resultado es que tienes latencias absurdas, trazas que parecen mapas de metro y fallos en cascada. Y hay una variante de este olor que no viene de tu código, sino del de los demás. La gente de seguridad la llama tangled dependency trees. Árboles de dependencias enredadas. Tu servicio importa una librería, que importa otras cinco, que importan otras veinte. Al final, llevas dentro cientos de piezas de terceros que nadie de tu equipo ha elegido a propósito. El ejemplo del libro es Log4Shell. En diciembre de 2021 apareció una vulnerabilidad en Log4j, una librería de Java para escribir logs que usa medio planeta. Bastaba con que tu aplicación registrase en el log un texto preparado por el atacante, por ejemplo, un nombre de usuario, para que éste pudiera ejecutar código en tu servidor. Un fallo de lo peor que hay. Pero lo interesante para nosotros no fue el parche, sino lo que vino antes del parche. Muchas empresas tardaron días o semanas en averiguar dónde la tenían. No la habían importado ellas, venía escondida en una dependencia de una dependencia. Es el mismo problema que el de tus microservicios a otra escala. No sabes de qué dependes hasta que se rompe. Muchos arquitectos que han pasado por estos microinfiernos cuentan historias casi calcadas. En su empresa se montaron microservicios sin disciplina, sin límites claros. Y el resultado fue una red compleja de llamadas entre servicios con dependencias ocultas. Cada nuevo servicio añadía una arista más al grafo hasta que no había forma humana de dibujar aquello en una pizarra sin que alguien se riera de forma nerviosa. Al final, cualquier cambio pequeño puede tener efecto sorpresa en sitios donde ni sabías que había relación. Si cada modificación es una ruleta rusa, nadie toca nada. Tu sistema se convierte en una instalación artística. Bonita desde fuera, pero mejor no tocarla por si se cae.

33:49 · Configuración por todas partes: el festival del sprawl

Vamos a hablar ahora de un olor más sutil. En inglés tiene nombre propio, configuration sprawl. La traducción es, has repartido la configuración por tantos sitios que ya nadie sabe qué valor manda. Lo de sprawl viene del urbanismo, el urban sprawl, que es cuando una ciudad crece a lo loco hacia afuera, urbanización tras urbanización, sin plan y sin centro. Pues esto es lo mismo, pero con tu configuración. Todo suele empezar de forma inocente. Tienes tu config.yml, estás contento. Un día quieres cambiar algo rápido sin tocar el fichero. Metes una variable de entorno. Otro día, alguien decide que mejor guardar esa configuración en una tabla de base de datos para poder cambiarla desde un panel. Otro equipo monta un microservicio de feature flags con su propia fuente de verdad. Pasa un tiempo y te encuentras con un fichero de configuración por servicio. Variables de entorno distintas en desarrollo, en pruebas y en producción. Una tabla de configuración en base de datos y flags en un panel interno. Y, de propina, algún valor metido a fuego en el código porque no daba tiempo a hacerlo otro. Cambias un timeout en producción y el efecto real es cero, porque en otra capa hay otro valor que lo sobrescribe. O peor aún, cambias algo y nada falla hasta dos semanas después, cuando se combina con otro flag y explota. Y esto no solo es incómodo, es peligroso. Cuando la configuración vive en mil sitios, nadie la revisa entera. Y ahí es donde se cuelan los valores que no deberían estar, como un permiso muy abierto, un almacenamiento expuesto a internet o una regla de firewall que alguien puso para probar y nunca quitó. En el mundo de la nube a esto se le llama errores de configuración. Y los informes de seguridad los colocan año tras año entre las principales causas de brechas y caídas. En 2019, Gartner llegó a predecir que hasta 2025 el 99% de los fallos de seguridad en la nube serían culpa del cliente, no del proveedor. Y casi siempre por configuración. Luego tenemos al primo de este olor, el secret sprawl. Tokens, claves, contraseñas, certificados, repartidos por repositorios, servicios, pipelines. Algunos en variables de entorno, otros en ficheros, otros en gestores de secretos, otros en apuntes de Notion que nadie debería tener pero todo el mundo tiene. Y esto ya no es solo un problema de seguridad, es de continuidad de negocio. Si no sabes dónde están tus secretos, tampoco sabes qué se rompe cuando los rotas, cuando caducan o cuando cambias de proveedor. ¿Y esto qué tiene que ver con la mantenibilidad? Pues todo. Si nadie entiende qué configuración está activa en cada entorno, cambiar el comportamiento del sistema es un acto de fe. Investigar un incidente es como participar en una gincana. Revisas ficheros de configuración, variables, tablas, flags, hasta que encuentras el valor maldito. Mientras tanto, el de sistemas que sabe cómo va de verdad ese laberinto prefiere no tocar nada. Solo se acerca cuando hay fuego. Y el resto mira desde lejos.

36:52 · Demasiados conceptos: tu modelo como museo

Sigamos. Otro olor maravilloso es el de los modelos de dominio inflados a base de duplicar conceptos. Entras en un proyecto y descubres que para algo tan sencillo como cliente tienes cinco tipos diferentes. Customer, client, user, account y profile. Todos se parecen. Ninguno es exactamente igual. Uno tiene el email, otro tiene la dirección, otro tiene el estado de alta, otro tiene los permisos, otro guarda el histórico de actividades. Según en qué parte del sistema estés, usas uno u otro. Y nadie sabe cuál es el bueno. Los estudios sobre code smells llaman a esto modelos redundantes. Varias clases que representan lo mismo y que complican entender el dominio. Y suele venir con un primo pequeño, los data clumps. Grupos de datos que siempre viajan juntos pero que nadie ha metido en una clase. Calle, número, ciudad y código postal pasando como cuatro parámetros sueltos por 20 métodos, en vez de vivir en una clase dirección. Cuando tienes cinco clientes apuesta lo que quieras a que la dirección anda desperdigada así en tres de ellos. Más allá de la teoría, el efecto que provoca esta situación es muy claro. Cualquier persona nueva se pierde. No sabe qué clase usar. No sabe dónde añadir un campo. No sabe si el cambiar un atributo en un sitio dejará otra clase desactualizada en otro lado. Para mí es como entrar en un museo lleno de esculturas repetidas, todas casi iguales pero ninguna con la placa correcta. La causa, otra vez, es humana. Cada equipo añade su versión del concepto cuando lo necesita. Es más rápido crear una clase nueva que entender lo que ya existe. Nadie limpia lo anterior. Nadie dice, eh, esto ya estaba, usemos lo mismo. Y al final tu modelo se convierte en un collage. Con piezas pegadas a lo largo de los años, sin criterio. Ojo que aquí hay trampa. La solución no es fundir los cinco en un único cliente gigante con todos los campos del mundo. Porque eso es fabricarte otra clase dios. Eric Evans en Domain Driven Design, el libro de 2003 que puso de moda hablar de dominios, defiende justo lo contrario. Que facturación y autenticación tengan cada una su propia idea de cliente puede ser perfectamente legítimo, siempre que esté claro dónde empieza y dónde acaba cada una. Él lo llama contextos delimitados. Lo que apesta no es que haya varios modelos. Lo que apesta es que nadie sepa por qué existen ni cuál manda en cada sitio. ¿Quién quiere mantener eso? Nadie. Porque cualquier cambio conceptual requiere antes una excavación arqueológica en media base de código.

39:26 · Cuando hasta la IA se rinde

Vamos a juntar todos los olores en una sola escena porque hay gente que ya la ha vivido. Un equipo decide adoptar herramientas de IA para generar código a toda pastilla. Durante seis meses las máquinas van escupiendo clases, servicios, helpers, funciones y todo parece avanzar muy rápido. No hay tiempo ni ganas de pensar demasiado en arquitectura. Ya refactorizaremos luego, que es la frase preferida de la deuda técnica. Un buen día alguien tiene que implementar una nueva funcionalidad relativamente sencilla. Lo cuenta después en un artículo en su blog de Medium. Le llevó tres días hacer algo que habría sido trabajo de mediodía. ¿Por qué? Porque el código estaba lleno de long methods, clases dios, modelos duplicados, lógica dispersa y acoplamientos raros. Había code smells por todas partes. Decía que cada cambio requería excavar en capas y capas de decisiones automáticas nunca revisadas. Y que ni la persona ni la herramienta que lo generó ni nadie tenían una visión global de cómo encajaban las piezas. Merece la pena pararse aquí porque esto rompe una fantasía moderna. No, el problema no es solo los humanos escriben mal. Si no diseñas límites, si no piensas en modelos, si no controlas dependencias, puedes generar basura a gran escala igual de bien con IA que con tus propios dedos. Las herramientas potencian lo que tú les das. Si les das disciplina, te ayudan. Si les das barra libre, multiplican tu caos. Desde el punto de vista de la mantenibilidad, el resultado es el mismo de siempre. Nadie quiere tocar eso. Ni humanos ni agentes de IA. Has construido un sistema hostil a la intervención.

41:07 · El miedo técnico

Hemos hablado de código. Vamos a hablar un segundo de personas. Cuando el diseño de un sistema apesta, la primera consecuencia no es un bug crítico. Es miedo. Miedo a cambiar cosas. Miedo a romper algo que no entiendes. Miedo a ser el de la incidencia. La literatura sobre mantenimiento lo repite. Los code smells se asocian con más defectos y más tiempo de cambio. Y cuando se juntan varios en el mismo sitio, peor. En 2021, un grupo de investigadores brasileños siguió durante tres meses a 14 desarrolladores mientras eliminaban 60 de esas combinaciones en proyectos reales, muchas con una clase dios de por medio. Lo que más les costaba no era la técnica de refactorización. Era entender el código. Y reconocían que seguían inseguros sobre si lo estaban haciendo bien. En la práctica, esto se traduce en escenas muy reconocibles. El senior que se apunta siempre al proyecto nuevo greenfield y esquiva como puede el sistema viejo que sostiene el negocio. El junior al que le asignan un par de cambios sencillos en la clase dios y que a partir de entonces mira esa parte del repositorio como si estuviera embrujada. El de sistemas que sabe que la configuración es una bomba y prefiere no cambiar nada mientras no haya un incendio. Se genera una cultura de miedo técnico. No se hacen cambios grandes, solo parches. Se aplazan decisiones importantes porque igual rompemos algo y así vamos tirando. Cada aplazamiento añade otra capa de olor. Y de repente, no es que tu equipo sea vago, es que tu sistema objetivamente es hostil al mantenimiento. Y la gente se protege como puede.

42:41 · La casa en ruinas

Te voy a dejar una metáfora visual para rematar. Tu sistema no es una catedral gótica perfecta que la gente por algún motivo desprecia. En muchos casos, es más bien una casa vieja, reformada a cachos, donde cada vez que levantas una baldosa sale un cable que nadie sabe dónde va. Algunas paredes están apuntaladas con madera. Otras tienen grietas que alguien tapó con cinta americana. Hay habitaciones que llevan cerradas desde 2012 porque ahí no entra nadie. Y de vez en cuando se oye un ruido raro en las tuberías. Y tú, con la casa así, le dices a un desarrollador. ¿Te apetece vivir aquí? ¿Hacer reformas? ¿Abrir tabiques? ¿Cambiar el baño? Y claro, la persona mira el bloque de pisos nuevo que se está empezando a construir en la parcela de al lado y dice Si no te importa, yo me voy al greenfield. Gracias. Las señales de que tu diseño apesta, como métodos gigantes, clases dios, dependencias cíclicas, configuración esparcida, demasiados conceptos duplicados, no son solo fealdades estéticas. Son razones muy prácticas por las que la gente no quiere tocar tu sistema. ¿Se puede revertir? Sí. Y no hace falta inventarse nada. Hay libros enteros sobre esto. Si tienes que empezar por uno, empieza por donde empezó todo, el refactoring de Fowler, el que te mencionaba antes. Además de ponerle nombre a cada olor, te explica cómo quitarlo paso a paso, en cambios pequeños y sin romper nada por el camino. Y si tu casa en ruinas no tiene test, que es lo más habitual, el libro es Working Effectively with Legacy Code, de Michael Feathers. Feathers define el código legacy de una forma que duele. Código sin test. Da igual que lo escribieras la semana pasada. Y aquí está la conexión con el miedo del que hablábamos antes. La gente no evita tocar el código por cobardía. Lo evita porque no hay red. Sin test que te avisen de lo que has roto, cada cambio es un salto al vacío. La propuesta de Feathers es empezar justo por ahí. Escribir tests que fijen lo que el sistema hace hoy, aunque lo haga mal, y solo entonces ponerse a trocear. Con red la gente salta. Y cuando se hace, se nota. Mejora la calidad y mejora la velocidad con la que puedes cambiar las cosas. Pero el primer paso es dejar de culpar al equipo porque no quiere mantener el sistema. Y hay que mirar al monstruo de frente. Igual el problema no es la actitud. Igual el problema es que has construido una casa en ruinas.

45:00 · Cierre y llamada a la acción

Te voy a dejar con un pensamiento para la próxima vez que tengas una tentación. Estás delante de un método ya larguito y piensas, solo un if más, por una excepción rara, y lo dejo. O tienes una clase manager que ya hace demasiado y dices, bah, meto aquí esta lógica, luego ya lo separo. Ese gesto tan pequeño, esa pereza, es exactamente así como se construyen las clases dios y los métodos Frankenstein, que nadie quiere tocar después. Imagina a tu yo del futuro dentro de tres años abriendo ese fichero, mirando esa condición rara, diciendo, ¿quién fue el animal que hizo esto? Y te das cuenta durante medio segundo de que estás a punto de responder, yo. A partir de ahí, haz lo que quieras. Pero al menos huele el código mientras lo escribes. Si huele raro hoy, mañana va a apestar. Y si en algún momento del episodio has pensado, esto es mi proyecto, o esto se lo tengo que pasar a alguien, ya sabes qué hacer. Suscríbete para no perderte el próximo y mandárselo a esa persona. Si te apetece, puedes echar una ojeada a mi web, pressanykey.tech, donde tienes mucha más información sobre el tema del que he hablado hoy y sobre otros igual o más interesantes. Y además puedes ver cómo contactar conmigo por si quieres criticarme un rato.

46:17 · Avance del siguiente programa

Me gustaría avanzarte de qué te voy a hablar en el próximo episodio. El problema es que ni lo sé yo todavía. Quizás te sorprenda.

46:25 · Despedida

Gracias por estar al otro lado, por darle una oportunidad a este invento y por seguir queriendo entender un poco mejor cada día el mundo de la tecnología y el software y a las personas que lo hacemos. Soy Lino y esto ha sido Press Any Key.

46:39 · Outro

Hasta otra. Hala, ¿todo el mundo contento ya? ¿Ya habéis armado bulla a gusto? ¡Pues ahora, a recoger! Que esta fiesta no se va a limpiar sola. ¿Cómo que birras en el bar? ¿Y esto quién lo recoge?