Escribir software es un acto que, aparentemente, cualquiera puede realizar. Te sientas, enciendes un ordenador, abres un IDE, un editor, VI si tienes el corazón puro o cualquier otra cosa (sí, también vale el Notepad) y empiezas a teclear.
Ni siquiera hacen falta especificaciones detalladas: ¿para qué sirven cuando lo tienes todo en la cabeza? A veces basta con una idea y las ganas de conseguir un resultado. Y algo, inevitablemente, sucede.
El primer «Hello World» es siempre un momento mágico, pero es solo el principio.
Superado el primer obstáculo, se descubre que escribir software es un proceso continuo de aprendizaje y adaptación. Aunque al principio es complicado, con el tiempo se aprenden los rudimentos: frameworks, librerías, patrones de diseño. Se entiende cómo estructurar el código, cómo modularizarlo, cómo probarlo. Y al final, tras días o semanas de trabajo, se obtiene algo que funciona —quizás no exactamente como lo teníamos en la cabeza, pero funciona: y en ese momento es una explosión de adrenalina y satisfacción.
Incluso los más pesimistas, esos a los que les cuesta pedir hasta un vaso de agua a su madre, tras horas, días y semanas siempre encuentran una solución.
Antes estaban los amigos, luego llegaron los foros. Hoy podemos incluso confiar en una inteligencia artificial o un agente: escribimos nuestra idea, aunque sea con errores gramaticales, y empieza la magia.
Pero hoy no quiero hablar de esto. Dejemos de lado por una vez el aspecto romántico de la programación, la creencia popular de que basta con poner las manos en un teclado para hacer cosas increíbles, y no hablemos de cómo se construye el software o de cómo se llega a un resultado: el mundo está lleno de cursos y manuales.
De lo que me gustaría hablar hoy es de uno de los aspectos más complejos y menos discutidos de la programación: el coraje de eliminar código.
El verdadero desafío no es un programa que funcione
El resultado es solo el primer escalón de la construcción de un software. Cualquier programador, más o menos convencido de sus propios medios, dirá siempre que puede conseguirlo. Quizás mienta un poco sobre los tiempos o los objetivos reales, pero su respuesta siempre será: «Puedo hacerlo». (Excluyo de este grupo a los pesimistas crónicos que empiezan diciendo «es imposible»; a esos los descartaremos por practicidad).
El verdadero desafío no es, por tanto, entregar un programa que funcione. El verdadero desafío es no dejarse abrumar por el propio software: no perder el control, no transformar un banal servicio REST de 10 líneas en un monstruo devora-discos (y hablo por experiencia personal).
El crecimiento del software es entropía y el trabajo del programador experto es combatir esta entropía.A menudo se compara el código con un activo, cuando en realidad es un pasivo. Si razonamos pensando que el código que escribimos es un patrimonio, perdemos el aspecto más fundamental de todo el proceso de creación: cuando escribimos código estamos creando una deuda. Cada línea de código debe ser leída, entendida, mantenida, probada y, un día, actualizada o eliminada.
Cuanto menos código hay, menor es la superficie de ataque para los bugs y menor es el coste de mantenimiento.
Esto a menudo se subestima, especialmente en contextos empresariales donde el foco está en «entregar funcionalidades» más que en «mantener un código sano y manejable».
Quien trabaja para empresas de producto iluminadas debería saber lo importante que es también el mantenimiento, la eliminación del código obsoleto, la gestión de las dependencias. Porque un software nunca está «terminado». Es un organismo vivo que evoluciona, crece, a veces enferma. Cuando falta esta visión, falta una planificación que tarde o temprano llevará inevitablemente al colapso.
He tenido la suerte/mala suerte de seguir ambos tipos de proyectos. Algunos donde solo había un objetivo: entregar, y que con el tiempo implosionaron en toneladas de código descoordinado; otros en los que era normal hacer refactorización continua, eliminar código obsoleto y mantener una base de código limpia y mantenible. La diferencia entre los dos mundos es abismal.
Todos somos acumuladores compulsivos
¿Conocéis el programa «Tú ensucia que yo limpio» (o «Acumuladores compulsivos»)? Personas que acumulan objetos inútiles, llenando sus casas hasta hacerlas invivibles. El software sufre de la misma patología.
Ya sea que lo escribamos nosotros o, peor, que lo haga una IA, el código empieza a aumentar de volumen. Primero pocas clases, pocas funciones y pocos scripts, pero con el tiempo nos encontramos inundados no solo de nuestro código, sino también de dependencias externas, librerías, módulos, plugins. Admito que yo también he caído varias veces en esta vorágine, dado que me impongo que cada repositorio que creo sea autocontenido, con todas las dependencias necesarias para funcionar: he visto proyectos bloquearse por la falta de una sola librería.
Los VibeCoders que me lean quizás no me entiendan aún, pero con el tiempo se darán cuenta de que las IAs tienen un solo objetivo: producir código que funcione y, si no lo hace, autoconvencerse de que sí.
El último objetivo de una IA es optimizar el código o reducir su complejidad: este aspecto no es importante para ellas y, por ahora, está delegado completamente a nosotros los humanos. Si los «humanos» no se preocupan del problema, mucho menos se preocuparán las IAs por nosotros.
Es aquí donde nuestro papel cambia radicalmente. Las IAs generativas son potentes «fábricas de añadidos», capaces de escribir miles de líneas en pocos segundos. Esto desplaza el papel del humano de «escritor» a «editor» o «curador». Nuestra habilidad más importante se convertirá en la capacidad de validar, simplificar y rechazar el código generado por la IA, no solo de producirlo. Por esto es importante dar una guía a las herramientas basadas en el vibe: no basta con decir «genera un CRM», debemos tener en la cabeza la arquitectura, las dependencias, el mantenimiento futuro y, en consecuencia, dividir todo dando un bocado a la vez a la IA.
Si queréis daros cuenta de si estáis al borde del abismo o ya en caída libre, haced una prueba: inspeccionad la carpeta node_modules de un proyecto vuestro, o las creadas por Maven o NuGet. En un proyecto mío bastante simple tengo 1 MB de mi código y 20 MB de node_modules. La sensación de que se me ha ido de las manos es muy alta y apenas estoy al inicio del proyecto.
¿Os habéis preguntado alguna vez: «¿Por qué mi ‘Hello World’ de tres líneas requiere 200 MB de dependencias?»? Si nunca lo habéis hecho, hacedlo. Descubriréis un mundo nuevo, a menudo subestimado, que puede transformar un proyecto simple en una pesadilla de mantenimiento.
Chateando con otros programadores escucho a menudo frases como esta:
No me he pasado de Vue 2 a Vue 3 porque tengo 18 dependencias que no puedo actualizar sin reescribir la mitad del proyecto.Parece una excusa, pero es una realidad con la que muchos desarrolladores se enfrentan a diario.
Las dependencias a menudo se toman a la ligera: acumulamos una montaña de funcionalidades sin una verdadera razón. Se añade, se añade, y luego se añade más. Es fácil añadir una funcionalidad, especialmente si la petición llega de un cliente o de un product manager. Pero raramente nos paramos a preguntar: «¿Es realmente necesaria esta funcionalidad?» y sobre todo nunca se vuelve atrás.
Este fenómeno tiene un nombre: feature creep.
Feature Creep: el enemigo silencioso
La pregunta que debemos hacernos cada día, cuando vemos una línea de código parada desde hace años, es: «¿Es realmente necesaria?»
La respuesta a menudo es «no». Pero actuar frente a ese «no» es costoso. Explicarlo a un cliente o a un product manager requiere una justificación técnica y verbal sólida, que pocos tienen el coraje, o la fuerza, de sostener.
El «feature creep» no es solo un problema de código, sino de producto. Una interfaz de usuario con demasiados botones, opciones y configuraciones sufre del mismo problema. El coraje de «quitar» se aplica también al Product Manager que dice «no» a una nueva funcionalidad para mantener el producto enfocado y simple.
Desconfiad también de quien os dice:
El problema es tu cliente pesado (fat client), no las dependencias que usas.Esto es solo una forma de desviar la atención del verdadero problema: la acumulación incontrolada de código y dependencias. No es que una arquitectura tenga una ventaja sobre otra, el problema de la acumulación compulsiva sigue siendo el mismo.
Siendo muy quisquillosos, un cliente pesado podría tener ventajas respecto a un cliente ligero seccionado en N servicios, dado que representa un único punto de control, frente a verificar servicios que son, virtualmente, utilizados por un número incontrolado de clientes, pero eso es otro tema.
Las funcionalidades superfluas y las dependencias fuera de control lo complican todo. El software se vuelve frágil, lento, difícil de mantener. La deuda técnica crece de forma invisible, hasta que se vuelve imposible ignorarla.
La pesadilla del mantenimiento
Mientras estamos «con la cabeza en el proyecto» y trabajamos a diario en features y refactorización, tenemos alguna probabilidad adicional de conseguir gestionar el caos. Pero inevitablemente, si ese proyecto se deja de lado y después de meses se retoma, o si el equipo varía mucho, la inevitable deriva es el caos y el aumento de la deuda técnica.
Cuanto mayor es el número de dependencias importadas, mayor es el problema de la obsolescencia transversal.
Pero con «dependencias» no pensamos solo en la librería X o Y que usamos para hacer el parsing de un archivo JSON. Pensamos en todo el ecosistema: versiones de lenguaje, librerías, frameworks, toolchain, sistemas de build, entornos de ejecución y demás.
A veces se acaba en un callejón sin salida técnico: la actualización que necesitamos entra en conflicto con otra librería fundamental, que aún no ha sido actualizada o cuyo mantenedor ha desaparecido en la nada. Poco importa si es open source, también este es un concepto sobrevalorado en el desarrollo de software.
En ese punto las opciones son pocas: reescribir partes del software, aceptar el agujero de seguridad, o dejar todo como está, esperando que no se derrumbe.
Es fácil decir «mi software es perfecto». Puede ser cierto para las líneas que has escrito tú —aunque a menudo son solo sesgos— pero no lo es para el ecosistema de componentes externos sobre el que se apoya.
¿Por qué no quitamos?
Pero ¿por qué no quitamos? Porque tenemos miedo. Miedo de romper algo («¿Y si este código servía para ese caso X que no he probado?»).
Para quitar con coraje hacen falta dos cosas fundamentales: seguridad técnica y psicológica, pero sobre todo la voluntad de hacerlo.
Hace falta también una cultura empresarial que premie la sustracción.
En muchas empresas, la productividad se mide en «funcionalidades entregadas» o «tickets cerrados». Pero ¿cuántas veces un programador es alabado por haber eliminado 1000 líneas de código obsoleto? Una «Pull Request» con -1000 líneas debería ser celebrada. Hace falta una cultura que vea la refactorización y la limpieza no como «tareas domésticas», sino como parte integrante y noble del proceso de desarrollo.
El coraje de quitar
Los verdaderos programadores son aquellos capaces de reducir.
Ken Thompson, cocreador de Unix y del lenguaje C, dijo una vez:
Uno de mis días más productivos fue eliminar 1000 líneas de código.No sé cuánto de cierta es esta afirmación, pero el concepto es potente. La verdadera maestría no está en añadir, sino en saber quitar sin perder funcionalidad.
También hay una frase famosa de Tony Hoare, el inventor de Quicksort:
Hay dos formas de diseñar software: una es hacerlo tan simple que sea obvio que no tiene defectos, la otra es hacerlo tan complicado que no haya defectos obvios. El primer método es mucho más difícil.¿Cómo no darle la razón? Además, su licenciatura en letras, anterior a su carrera informática, le daba quizás una ventaja para comprender la elegancia de la simplicidad.
Pero dado que no hay rosas sin espinas, además de esta perla, Hoare nos ha dejado también una de las mayores tragedias de la informática moderna: el concepto de «NULL POINTER». Si alguna vez os ha arruinado el día, ahora sabéis a quién dar las gracias.
Solo los valientes quitan cosas
Pero volvamos a nosotros. ¿Cómo se hace, concretamente, para quitar?
El primer paso es eliminar el código inútil. Parece fácil, pero es aquí donde saltan las resistencias, tanto estructurales como humanas. Para ganar esta batalla hacen falta armas adecuadas:
- Tests automáticos robustos: una suite de tests que dé la confianza de que, si se elimina algo esencial, un test fallará, protegiéndonos de regresiones inesperadas.
- Seguridad psicológica: un entorno de trabajo donde «romper» algo en un entorno de test o staging no sea un crimen, sino parte del proceso de aprendizaje y limpieza.
- Verificación continua del uso: ¿cuántas features se han implementado a petición de un cliente que hoy ya no lo es? ¿Cuántos procedimientos no son usados por nadie? Es fundamental hacerse estas preguntas y actuar en consecuencia.
- Afrontar el miedo al «¿y si un día hiciera falta?»: esta es la excusa más común para no borrar. Spoiler: ese día no llegará casi nunca. Y aunque llegase, las exigencias habrán cambiado hasta tal punto que reescribir el código desde cero será de todos modos la mejor opción, antes que adaptar una solución vieja y olvidada. El código escrito para una «futura implementación» es una hipoteca sobre el futuro que raramente se rescata.
El paso siguiente es simplificar las lógicas complejas y reducir al mínimo las dependencias. Existen casos virtuosos de software pensados para tener cero o poquísimas dependencias, precisamente para facilitar la difusión y el mantenimiento.
Todo proyecto de software que se precie debería dedicar tiempo a eliminar y limpiar, como un ritual sagrado. Cada línea de código es un peso, una responsabilidad que llevamos con nosotros. Cada línea que añadimos es una línea que tendremos que mantener, probar y sobre la que tendremos que hacer debug.
No es un drama borrar. Con los sistemas de control de versiones como Git, siempre podemos recuperar lo que se ha eliminado. Pero la verdad es que, nueve de cada diez veces, ese código era solo lastre.
La verdadera maestría es la simplicidad
Es fácil añadir. Todos son buenos añadiendo. ¿Pero quitar? Es ahí donde se juega el verdadero partido.
La maestria de un desarrollador senior se mide no tanto por cuánto código sabe escribir, sino por cuánto código sabe eliminar preservando las funcionalidades esenciales.
Lo que nos frena es el miedo al «no lo quito porque quizás sirva mañana». Pero ese «mañana» no llega casi nunca. Como afirma el principio YAGNI (You Aren’t Gonna Need It): si no lo necesitas ahora, no lo implementes.
El verdadero valor no está en añadir, sino en destilar lo esencial, eliminar el ruido y construir algo que funcione de verdad. Este es el coraje de quitar. Y es esto lo que diferencia a un programador iluminado de alguien que no ve más allá de su propio fin de semana.
