"Cualquier tonto puede escribir código que un ordenador entienda": la clave de los buenos programadores
Elígenos como tu fuente preferida en Google.
Durante los 90 se popularizó la idea del mal olor del código, una realidad que parece haber resurgido con fuerza ante el avance de la programación con inteligencia artificial.
A finales de la década de los 90 los programadores estaban totalmente saturados por la burbuja de las puntocom, teniendo que cumplir con fechas límite para entregar resultados que, inevitablemente, acaban teniendo fallos en la sombra del código.
Cada línea de código que se quisiera modificar llevaba asociadas semanas y semanas de trabajo incansable; esto mismo llevó durante aquella estresante época a que existieran errores en cadena que, en una especie de círculo vicioso, requerían de echar aún muchas más horas de trabajo.
Justo en 1999 se publicó el libro Refactoring: improving the design of existing code, que conceptualizó lo que estaba ocurriendo en la industria del software: el código no estaba roto en absoluto, sino que estaba comenzando a oler mal.
Este libro, escrito por el británico Martin Fowler, quien entonces era consultor de diseño orientado a objetos y más adelante se convertiría en el científico jefe de ThoughtWorks, popularizó el concepto "olor del código" –code smell en el término original.
No obstante, atribuyó también el mérito a Kent Beck, una de las personalidades más importantes del desarrollo ágil, además de crear el método Extreme Programming (XP), que ayudó a escribir el capítulo titulado Malos olores en el código.
El mal olor en el código, aunque pueda parecer ya un término prehistórico en el mundo de la informática, diferencia las buenas prácticas en programación de las que no lo son. Y, cómo no, la era actual ha vuelto a hacer sonar con fuerza este término.
Por qué el código comienza a oler mal
La idea original proviene de un ejemplo de la rutina a la que Beck se enfrentaba día a día. El olor del código no es un error por sí mismo –aunque puede serlo–, sino más algo parecido al mal olor de un brik de leche que lleva tiempo en la nevera o el olor de un pañal.
El mal olor no implica que la estructura esté totalmente destruida, sino que da pistas de que algo no funciona muy bien y es una señal de alerta de que hay que actuar, ya que algo se está echando a perder en el fondo. De ahí, el mal olor del código.
Es muy parecido a lo que se conoce como bug, aunque hay una ligera diferencia. El bug podría definirse como un error lógico que provoca que el programa acabe realizando cálculos erróneos, mientras que el código maloliente sí ejecuta de forma perfecta lo que pida el usuario. Como ya habrás pensado, está relacionado con lo que se conoce como deuda técnica, un término acuñado por Ward Cunningham.
De vuelta al libro de Fowler, en aquella época la industria se estaba centrando cada vez más en conseguir una mejor optimización de la RAM, la reducción de los ciclos del reloj del procesador y todo para ganar milisegundos en las tareas de ejecución.
Para el autor, más del 80% del coste total del software comercial se destinaba al mantenimiento del código y no a la escritura inicial, por lo que centrarlo todo en RAM, ciclos del reloj y un código cada vez más complejo era totalmente absurdo.
Y lo resumió perfectamente con una frase que pasaría a la historia de la informática: "Cualquier tonto puede escribir código que un ordenador entienda. Los buenos programadores escriben código que los humanos pueden entender".
El mal olor que la IA está dejando ya en el código
La deuda técnica del código es una de las peores consecuencias de que el código empiece a oler mal, ya que si los programadores no realizan un buen diseño desde el comienzo –por prisa, exigencia o causas ajenas a los mismos– se acumula esta especie de interés compuesto que, en el futuro, tendrán que solucionar otros programadores.
Durante la explosión de la inteligencia artificial generativa y modelos como GitHub Copilot, Claude Code, etc. se comenzó a asegurar que esta deuda técnica se reduciría: comenzaron los despidos masivos de programadores humanos y llegaron las plataformas de IA salvadoras, que aligeraban el tiempo de ejecución.
Y todo pareció volver a los años 90, hasta que en unos pocos meses las mismas empresas se dieron de bruces con que los costes no se habían reducido e incluso tenían que volver a contratar a programadores humanos para arreglar un código que ya comenzaba a apestar.
Un ser humano puede trabajar desde la empatía para ofrecer el código más limpio posible para los futuros revisores y mantenedores, pero la IA no tiene esa capacidad, y menos aún ante el auge del vibecoding, que suele usar gente sin conocimientos en programación.
En la actualidad, ya existen muchos conceptos que hablan sobre los errores –mejor dicho, los malos olores– que la IA está descubriendo con el código producido por esta, y que sea más rápida no quiere decir que sea más eficiente.
En primer lugar, aparece lo que se conoce como AI Bloat, que se refiere a la sintaxis que utilizan las herramientas de IA para generar código, ya que no suelen reutilizar abstracciones que ya existen en un proyecto, sino que se dedican a generar funciones que parecen haber descubierto el fuego de nuevo.
En segundo lugar, lo que se conoce como acoplamiento fantasma, que significa que la IA utilizará dependencias que no se necesitan para el proyecto y, en el peor de los casos, métodos que pueden vulnerar el principio de menor conocimiento.
Por último, dentro de las arquitecturas basadas en la nube, es bastante común que la IA comience a sugerir integraciones directas con otros microservicios, pero sin capas de desacoplamiento, por lo que cambiar un esquema de datos en este entorno suele dar paso a tener que editar decenas y decenas de funciones aisladas.
Curiosamente, en la actualidad crear 400 líneas de código no es nada complicado con la IA y lo hará en apenas unos segundos; desafortunadamente, esto hace que se vuelva al punto de partida del que habló Martín Fowler en 1999.
Con el avance imparable de la IA, parece que el trabajo de los buenos programadores humanos se ha hecho más que necesario. Es obligatorio si se quiere comenzar un proyecto de la mejor forma y, en el futuro, para no tener que echar perfume al mal olor que ha ido dejando la IA.