Lo que debes de saber
- Ken Thompson, co-creador de Unix, valora más borrar que escribir código.
- Su filosofía choca con la cultura actual de ‘más funciones, más complejidad’.
- Noticias recientes muestran los costos de la complejidad innecesaria en tech.
- La simplicidad es un lujo que pocas empresas pueden permitirse hoy.
La herejía del creador: celebrar lo que se quita
Imagina que el ingeniero que diseñó los cimientos de tu casa te dice que su mejor día de trabajo fue cuando derribó una pared. Algo así es lo que propone Ken Thompson, una leyenda viva de la informática y co-creador del sistema operativo Unix. En una entrevista recogida por Msn, Thompson declaró sin ambages: «Uno de mis días más productivos fue cuando borré 1.000 líneas de código». Suena a chiste, a una provocación intelectual, pero en realidad es un diagnóstico brutal de la industria tecnológica actual. Mientras las empresas miden la productividad de sus desarrolladores en líneas de código escritas, commits realizados o features añadidas, un pionero viene a recordar que el verdadero valor, la elegancia y la eficiencia, a menudo están en lo que se elimina. No es solo una anécdota curiosa; es un principio de diseño que choca frontalmente con el modelo de negocio de casi todo el software moderno, basado en la acumulación perpetua de funciones, capas de abstracción y deuda técnica disfrazada de innovación.
La reflexión de Thompson no es nueva para los puristas, pero suena revolucionaria en 2026. Hoy, el ecosistema tech que él ayudó a crear está dominado por una lógica opuesta. Observa los titulares del podcast AirFeeds de Enramos: «AWS corrige fallos críticos», «Se filtra la placa base del NVIDIA N1X con 128 GB de RAM», «Ubuntu 26.04 LTS tiene unos requisitos más altos que Windows 11». Cada noticia es un monumento a la complejidad. Más potencia, más memoria, más requisitos, más capas de software que necesitan más parches. Es la antítesis de la filosofía Unix original, que premiaba la simplicidad, los programas que hacían una cosa bien y la composición de herramientas pequeñas. Thompson y su compañero Dennis Ritchie construyeron un sistema que cabía en la memoria de una máquina ridículamente pequeña para los estándares actuales. Hoy, el sistema operativo de tu teléfono es miles de veces más complejo, y no necesariamente miles de veces más útil para tareas básicas.
«Uno de mis días más productivos fue cuando borré 1.000 líneas de código.» – Ken Thompson, citado en Msn.
¿Dónde se materializa el costo de haber olvidado esta lección? En todas partes. El podcast de Enramos también menciona el cable «ASUS ROG Equalizer», una solución de hardware para evitar que las tarjetas gráficas RTX 40 y RTX 50 «se quemen». Es decir, la complejidad y el consumo desbocado de los nuevos componentes son tales que se necesitan accesorios especiales para evitar un desastre físico. Es la paradoja perfecta: agregamos tanta complejidad (más transistores, más velocidad, más watts) que luego debemos agregar aún más complejidad (cables especiales, disipadores enormes, software de monitoreo) para gestionar los problemas que la primera complejidad creó. Thompson, desde su perspectiva de ingeniero de sistemas, probablemente vería esto como un fracaso de diseño. Un sistema bien diseñado es elegante, eficiente y no necesita parches sobre parches para funcionar sin incendiarse. Pero la lógica del mercado no premia la elegancia; premia la hoja de especificaciones, el número de teraflops, la lista interminable de funciones aunque nadie las use.
La simplicidad es un lujo que pocos pueden pagar
La anécdota de Thompson expone una tensión fundamental: la que existe entre la ingeniería de calidad y las presiones comerciales. Borrar 1,000 líneas de código implica tener la confianza, el tiempo y la autoridad para decir «esto sobra». Implica un profundo entendimiento del sistema y una libertad que rara vez existe en las corporaciones modernas. ¿Qué jefe de proyecto en Google, Meta o Microsoft celebraría que su equipo pasó un día entero borrando código en lugar de agregar una nueva función para la próxima revisión trimestral? La métrica falla. La cultura corporativa, obsesionada con el crecimiento infinito y la «disrupción», no tiene espacio para la refinación, la poda, la simplificación. Es más fácil vender «IA en tus lentes de contacto» (una nota curiosa que, irónicamente, llevaba a un error 404 en un sitio de noticias deportivas belga, según Sporting Charleroi Be) que vender «este software ahora es más estable y consume menos recursos porque quitamos cosas».
El caso de OpenAI pausando ‘Stargate UK’, también reportado en el podcast, es otro síntoma. El proyecto se detiene porque la electricidad en Reino Unido es cuatro veces más cara que en EE.UU. y por problemas de regulación de copyright. Es decir, la complejidad no es solo técnica; es legal, logística, económica. Construir sistemas de inteligencia artificial gigantescos requiere una infraestructura monstruosa, y cuando los costos se disparan, incluso los gigantes tienen que dar marcha atrás. Thompson trabajaba en una era donde los límites físicos (memoria, procesamiento) forzaban la creatividad y la simplicidad. Hoy, esos límites se han empujado tanto con dinero y hardware que la disciplina se ha relajado. El resultado es software hinchado, hardware que requiere refrigeración líquida para tareas básicas, y una huella de carbono digital que nadie quiere contabilizar. La productividad de borrar no es solo una cuestión de código limpio; es una cuestión de sostenibilidad. Cada línea de código innecesaria consume electricidad en algún servidor, en algún centro de datos.
El legado incómodo de un minimalista
Lo más irónico de todo es que el propio Unix, la criatura de Thompson, no escapó a esta dinámica. Los sistemas Unix-like modernos, como Linux, son enormes y complejos. Pero el núcleo de la filosofía, la idea de que las herramientas deben ser simples, componibles y hacer bien una cosa, sigue siendo un faro para muchos desarrolladores. Es un recordatorio de que el progreso no siempre significa agregar. A veces, el avance más significativo es reconocer el desorden y tener el valor de deshacerlo. En un mundo donde un Boeing 737 abandonado puede acumular multas de aparcamiento durante 14 años (como cuenta otra nota del podcast), la lección es clara: la complejidad no gestionada se convierte en una carga, en una factura que llega tarde o temprano. Ken Thompson, desde su retiro, nos lanza una pregunta incómoda: ¿Estamos midiendo lo que realmente importa? ¿O solo estamos contando líneas de código, megapíxeles y gigahertz, mientras el verdadero trabajo —el de simplificar, refinar, hacer las cosas bien— queda sin reconocer y, lo que es peor, sin valorar?
