{"id":34618,"date":"2026-01-26T15:22:18","date_gmt":"2026-01-26T14:22:18","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=34618"},"modified":"2026-01-26T15:29:51","modified_gmt":"2026-01-26T14:29:51","slug":"menos-es-mas-tambien-en-programacion","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/es\/uncategorized-es\/menos-es-mas-tambien-en-programacion\/","title":{"rendered":"Menos es m\u00e1s\u2026 tambi\u00e9n en programaci\u00f3n"},"content":{"rendered":"\n

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\u00f3n puro o cualquier otra cosa (s\u00ed, tambi\u00e9n vale el Notepad) y empiezas a teclear.<\/p>\n\n\n\n

Ni siquiera hacen falta especificaciones detalladas: \u00bfpara qu\u00e9 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.<\/p>\n\n\n\n

El primer “Hello World” es siempre un momento m\u00e1gico, pero es solo el principio.<\/p>\n\n\n\n

Superado el primer obst\u00e1culo, se descubre que escribir software es un proceso continuo de aprendizaje y adaptaci\u00f3n. Aunque al principio es complicado, con el tiempo se aprenden los rudimentos: frameworks, librer\u00edas, patrones de dise\u00f1o. Se entiende c\u00f3mo estructurar el c\u00f3digo, c\u00f3mo modularizarlo, c\u00f3mo probarlo. Y al final, tras d\u00edas o semanas de trabajo, se obtiene algo que funciona \u2014quiz\u00e1s no exactamente como lo ten\u00edamos en la cabeza, pero funciona: y en ese momento es una explosi\u00f3n de adrenalina y satisfacci\u00f3n.<\/p>\n\n\n\n

Incluso los m\u00e1s pesimistas, esos a los que les cuesta pedir hasta un vaso de agua a su madre, tras horas, d\u00edas y semanas siempre encuentran una soluci\u00f3n.<\/p>\n\n\n\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.<\/p>\n\n\n\n

Pero hoy no quiero hablar de esto. Dejemos de lado por una vez el aspecto rom\u00e1ntico de la programaci\u00f3n, la creencia popular de que basta con poner las manos en un teclado para hacer cosas incre\u00edbles, y no hablemos de c\u00f3mo se construye el software o de c\u00f3mo se llega a un resultado: el mundo est\u00e1 lleno de cursos y manuales.<\/p>\n\n\n\n

De lo que me gustar\u00eda hablar hoy es de uno de los aspectos m\u00e1s complejos y menos discutidos de la programaci\u00f3n: el coraje de eliminar c\u00f3digo.<\/p>\n\n\n\n

El verdadero desaf\u00edo no es un programa que funcione<\/h2>\n\n\n\n

El resultado es solo el primer escal\u00f3n de la construcci\u00f3n de un software. Cualquier programador, m\u00e1s o menos convencido de sus propios medios, dir\u00e1 siempre que puede conseguirlo. Quiz\u00e1s mienta un poco sobre los tiempos o los objetivos reales, pero su respuesta siempre ser\u00e1: “Puedo hacerlo”. (Excluyo de este grupo a los pesimistas cr\u00f3nicos que empiezan diciendo “es imposible”; a esos los descartaremos por practicidad).<\/p>\n\n\n\n

El verdadero desaf\u00edo no es, por tanto, entregar un programa que funcione. El verdadero desaf\u00edo es no dejarse abrumar por el propio software: no perder el control, no transformar un banal servicio REST de 10 l\u00edneas en un monstruo devora-discos (y hablo por experiencia personal).<\/p>\n\n\n

El crecimiento del software es entrop\u00eda y el trabajo del programador experto es combatir esta entrop\u00eda.<\/code><\/span><\/pre>\n\n\n
A menudo se compara el c\u00f3digo con un activo, cuando en realidad es un pasivo. Si razonamos pensando que el c\u00f3digo que escribimos es un patrimonio, perdemos el aspecto m\u00e1s fundamental de todo el proceso de creaci\u00f3n: cuando escribimos c\u00f3digo estamos creando una deuda. Cada l\u00ednea de c\u00f3digo debe ser le\u00edda, entendida, mantenida, probada y, un d\u00eda, actualizada o eliminada.<\/p>\n\n\n\n
Cuanto menos c\u00f3digo hay, menor es la superficie de ataque para los bugs y menor es el coste de mantenimiento.<\/p>\n\n\n\n
Esto a menudo se subestima, especialmente en contextos empresariales donde el foco est\u00e1 en “entregar funcionalidades” m\u00e1s que en “mantener un c\u00f3digo sano y manejable”.<\/p>\n\n\n\n
Quien trabaja para empresas de producto iluminadas deber\u00eda saber lo importante que es tambi\u00e9n el mantenimiento, la eliminaci\u00f3n del c\u00f3digo obsoleto, la gesti\u00f3n de las dependencias. Porque un software nunca est\u00e1 “terminado”. Es un organismo vivo que evoluciona, crece, a veces enferma. Cuando falta esta visi\u00f3n, falta una planificaci\u00f3n que tarde o temprano llevar\u00e1 inevitablemente al colapso.<\/p>\n\n\n\n
He tenido la suerte\/mala suerte de seguir ambos tipos de proyectos. Algunos donde solo hab\u00eda un objetivo: entregar, y que con el tiempo implosionaron en toneladas de c\u00f3digo descoordinado; otros en los que era normal hacer refactorizaci\u00f3n continua, eliminar c\u00f3digo obsoleto y mantener una base de c\u00f3digo limpia y mantenible. La diferencia entre los dos mundos es abismal.<\/p>\n\n\n\n
Todos somos acumuladores compulsivos<\/h2>\n\n\n\n
\u00bfConoc\u00e9is el programa “T\u00fa ensucia que yo limpio” (o “Acumuladores compulsivos”)? Personas que acumulan objetos in\u00fatiles, llenando sus casas hasta hacerlas invivibles. El software sufre de la misma patolog\u00eda.<\/p>\n\n\n\n
Ya sea que lo escribamos nosotros o, peor, que lo haga una IA, el c\u00f3digo 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\u00f3digo, sino tambi\u00e9n de dependencias externas, librer\u00edas, m\u00f3dulos, plugins. Admito que yo tambi\u00e9n he ca\u00eddo varias veces en esta vor\u00e1gine, 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\u00eda.<\/p>\n\n\n\n
Los VibeCoders que me lean quiz\u00e1s no me entiendan a\u00fan, pero con el tiempo se dar\u00e1n cuenta de que las IAs tienen un solo objetivo: producir c\u00f3digo que funcione y, si no lo hace, autoconvencerse de que s\u00ed.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
El \u00faltimo objetivo de una IA es optimizar el c\u00f3digo o reducir su complejidad: este aspecto no es importante para ellas y, por ahora, est\u00e1 delegado completamente a nosotros los humanos. Si los “humanos” no se preocupan del problema, mucho menos se preocupar\u00e1n las IAs por nosotros.<\/p>\n\n\n\n
Es aqu\u00ed donde nuestro papel cambia radicalmente. Las IAs generativas son potentes “f\u00e1bricas de a\u00f1adidos”, capaces de escribir miles de l\u00edneas en pocos segundos. Esto desplaza el papel del humano de “escritor” a “editor” o “curador”. Nuestra habilidad m\u00e1s importante se convertir\u00e1 en la capacidad de validar, simplificar y rechazar el c\u00f3digo generado por la IA, no solo de producirlo. Por esto es importante dar una gu\u00eda a las herramientas basadas en el vibe<\/em>: 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.<\/p>\n\n\n\n
Si quer\u00e9is daros cuenta de si est\u00e1is al borde del abismo o ya en ca\u00edda libre, haced una prueba: inspeccionad la carpeta node_modules<\/code> de un proyecto vuestro, o las creadas por Maven o NuGet. En un proyecto m\u00edo bastante simple tengo 1 MB de mi c\u00f3digo y 20 MB de node_modules. La sensaci\u00f3n de que se me ha ido de las manos es muy alta y apenas estoy al inicio del proyecto.<\/p>\n\n\n\n
\u00bfOs hab\u00e9is preguntado alguna vez: “\u00bfPor qu\u00e9 mi ‘Hello World’ de tres l\u00edneas requiere 200 MB de dependencias?”? Si nunca lo hab\u00e9is hecho, hacedlo. Descubrir\u00e9is un mundo nuevo, a menudo subestimado, que puede transformar un proyecto simple en una pesadilla de mantenimiento.<\/p>\n\n\n\n
Chateando con otros programadores escucho a menudo frases como esta:<\/p>\n\n\n
No me he pasado de Vue 2 a Vue 3 porque tengo 18 dependencias que no puedo actualizar sin reescribir la mitad del proyecto.<\/code><\/span><\/pre>\n\n\n
Parece una excusa, pero es una realidad con la que muchos desarrolladores se enfrentan a diario.<\/p>\n\n\n\n
Las dependencias a menudo se toman a la ligera: acumulamos una monta\u00f1a de funcionalidades sin una verdadera raz\u00f3n. Se a\u00f1ade, se a\u00f1ade, y luego se a\u00f1ade m\u00e1s. Es f\u00e1cil a\u00f1adir una funcionalidad, especialmente si la petici\u00f3n llega de un cliente o de un product manager. Pero raramente nos paramos a preguntar: “\u00bfEs realmente necesaria esta funcionalidad?” y sobre todo nunca se vuelve atr\u00e1s.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Este fen\u00f3meno tiene un nombre: feature creep.<\/p>\n\n\n\n
Feature Creep: el enemigo silencioso<\/h2>\n\n\n\n
La pregunta que debemos hacernos cada d\u00eda, cuando vemos una l\u00ednea de c\u00f3digo parada desde hace a\u00f1os, es: “\u00bfEs realmente necesaria?”<\/p>\n\n\n\n
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\u00f3n t\u00e9cnica y verbal s\u00f3lida, que pocos tienen el coraje, o la fuerza, de sostener.<\/p>\n\n\n\n
El “feature creep” no es solo un problema de c\u00f3digo, sino de producto. Una interfaz de usuario con demasiados botones, opciones y configuraciones sufre del mismo problema. El coraje de “quitar” se aplica tambi\u00e9n al Product Manager que dice “no” a una nueva funcionalidad para mantener el producto enfocado y simple.<\/p>\n\n\n\n
Desconfiad tambi\u00e9n de quien os dice:<\/p>\n\n\n
El problema es tu cliente pesado (fat client), no las dependencias que usas.<\/code><\/span><\/pre>\n\n\n
Esto es solo una forma de desviar la atenci\u00f3n del verdadero problema: la acumulaci\u00f3n incontrolada de c\u00f3digo y dependencias. No es que una arquitectura tenga una ventaja sobre otra, el problema de la acumulaci\u00f3n compulsiva sigue siendo el mismo.<\/p>\n\n\n\n
Siendo muy quisquillosos, un cliente pesado podr\u00eda tener ventajas respecto a un cliente ligero seccionado en N servicios, dado que representa un \u00fanico punto de control, frente a verificar servicios que son, virtualmente, utilizados por un n\u00famero incontrolado de clientes, pero eso es otro tema.<\/p>\n\n\n\n
Las funcionalidades superfluas y las dependencias fuera de control lo complican todo. El software se vuelve fr\u00e1gil, lento, dif\u00edcil de mantener. La deuda t\u00e9cnica crece de forma invisible, hasta que se vuelve imposible ignorarla.<\/p>\n\n\n\n
La pesadilla del mantenimiento<\/h2>\n\n\n\n
Mientras estamos “con la cabeza en el proyecto” y trabajamos a diario en features<\/em> y refactorizaci\u00f3n, tenemos alguna probabilidad adicional de conseguir gestionar el caos. Pero inevitablemente, si ese proyecto se deja de lado y despu\u00e9s de meses se retoma, o si el equipo var\u00eda mucho, la inevitable deriva es el caos y el aumento de la deuda t\u00e9cnica.<\/p>\n\n\n\n
Cuanto mayor es el n\u00famero de dependencias importadas, mayor es el problema de la obsolescencia transversal.<\/p>\n\n\n\n
Pero con “dependencias” no pensamos solo en la librer\u00eda X o Y que usamos para hacer el parsing de un archivo JSON. Pensamos en todo el ecosistema: versiones de lenguaje, librer\u00edas, frameworks, toolchain, sistemas de build, entornos de ejecuci\u00f3n y dem\u00e1s.<\/p>\n\n\n\n
A veces se acaba en un callej\u00f3n sin salida t\u00e9cnico: la actualizaci\u00f3n que necesitamos entra en conflicto con otra librer\u00eda fundamental, que a\u00fan no ha sido actualizada o cuyo mantenedor ha desaparecido en la nada. Poco importa si es open source, tambi\u00e9n este es un concepto sobrevalorado en el desarrollo de software.<\/p>\n\n\n\n
En ese punto las opciones son pocas: reescribir partes del software, aceptar el agujero de seguridad, o dejar todo como est\u00e1, esperando que no se derrumbe.<\/p>\n\n\n\n
Es f\u00e1cil decir “mi software es perfecto”. Puede ser cierto para las l\u00edneas que has escrito t\u00fa \u2014aunque a menudo son solo sesgos\u2014 pero no lo es para el ecosistema de componentes externos sobre el que se apoya.<\/p>\n\n\n\n
\u00bfPor qu\u00e9 no quitamos?<\/h2>\n\n\n\n
Pero \u00bfpor qu\u00e9 no quitamos? Porque tenemos miedo. Miedo de romper algo (“\u00bfY si este c\u00f3digo serv\u00eda para ese caso X que no he probado?”).<\/p>\n\n\n\n
Para quitar con coraje hacen falta dos cosas fundamentales: seguridad t\u00e9cnica y psicol\u00f3gica, pero sobre todo la voluntad de hacerlo.<\/p>\n\n\n\n
Hace falta tambi\u00e9n una cultura empresarial que premie la sustracci\u00f3n.<\/p>\n\n\n\n
En muchas empresas, la productividad se mide en “funcionalidades entregadas” o “tickets cerrados”. Pero \u00bfcu\u00e1ntas veces un programador es alabado por haber eliminado 1000 l\u00edneas de c\u00f3digo obsoleto? Una “Pull Request” con -1000 l\u00edneas deber\u00eda ser celebrada. Hace falta una cultura que vea la refactorizaci\u00f3n y la limpieza no como “tareas dom\u00e9sticas”, sino como parte integrante y noble del proceso de desarrollo.<\/p>\n\n\n\n
El coraje de quitar<\/h2>\n\n\n\n
Los verdaderos programadores son aquellos capaces de reducir.<\/p>\n\n\n\n
Ken Thompson, cocreador de Unix y del lenguaje C, dijo una vez:<\/p>\n\n\n
Uno de mis d\u00edas m\u00e1s productivos fue eliminar 1000 l\u00edneas de c\u00f3digo.<\/code><\/span><\/pre>\n\n\n
No s\u00e9 cu\u00e1nto de cierta es esta afirmaci\u00f3n, pero el concepto es potente. La verdadera maestr\u00eda no est\u00e1 en a\u00f1adir, sino en saber quitar sin perder funcionalidad.<\/p>\n\n\n\n
Tambi\u00e9n hay una frase famosa de Tony Hoare, el inventor de Quicksort:<\/p>\n\n\n
Hay dos formas de dise\u00f1ar 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\u00e9todo es mucho m\u00e1s dif\u00edcil.<\/code><\/span><\/pre>\n\n\n
\u00bfC\u00f3mo no darle la raz\u00f3n? Adem\u00e1s, su licenciatura en letras, anterior a su carrera inform\u00e1tica, le daba quiz\u00e1s una ventaja para comprender la elegancia de la simplicidad.<\/p>\n\n\n\n
Pero dado que no hay rosas sin espinas, adem\u00e1s de esta perla, Hoare nos ha dejado tambi\u00e9n una de las mayores tragedias de la inform\u00e1tica moderna: el concepto de “NULL POINTER”. Si alguna vez os ha arruinado el d\u00eda, ahora sab\u00e9is a qui\u00e9n dar las gracias.<\/p>\n\n\n\n
Solo los valientes quitan cosas<\/h2>\n\n\n\n
Pero volvamos a nosotros. \u00bfC\u00f3mo se hace, concretamente, para quitar?<\/p>\n\n\n\n
El primer paso es eliminar el c\u00f3digo in\u00fatil. Parece f\u00e1cil, pero es aqu\u00ed donde saltan las resistencias, tanto estructurales como humanas. Para ganar esta batalla hacen falta armas adecuadas:<\/p>\n\n\n\n