Pocas frases explican tan bien una forma de entender el software como la que se atribuye desde hace años a Ken Thompson: “Uno de mis días más productivos fue cuando tiré 1.000 líneas de código”. No es una ocurrencia cualquiera ni una consigna para redes sociales. Resume la filosofía de uno de los nombres más influyentes de la informática moderna, cocreador de Unix, diseñador del lenguaje B y uno de los impulsores originales de Go. El propio Computer History Museum recoge esa cita en su perfil biográfico de Thompson, lo que ha ayudado a convertirla en una especie de lema para generaciones de desarrolladores.
La idea sigue teniendo fuerza en 2026 porque choca de frente con una obsesión que todavía persiste en muchos equipos: medir la productividad por la cantidad de código escrito. Thompson, en cambio, representa justo lo contrario. Su trayectoria técnica, desde Bell Labs hasta Google, está atravesada por la misma intuición: un sistema suele mejorar cuando gana claridad, elimina capas innecesarias y reduce complejidad. No siempre programar más significa programar mejor. A veces, el mayor avance consiste en quitar.
El ingeniero que ayudó a definir cómo funciona el software moderno
Hablar de Ken Thompson no es hablar de un programador brillante más, sino de una figura fundacional. La ACM le concedió junto a Dennis Ritchie el Premio Turing de 1983 por el desarrollo de la teoría de sistemas operativos genéricos y, en particular, por la implementación de Unix, un sistema que cambió la forma de construir software y cuya influencia llega todavía al corazón de Linux, macOS, Android, BSD y buena parte de la infraestructura digital actual.
Unix no fue importante solo por lo que hacía, sino por cómo estaba pensado. La famosa “filosofía Unix” apostó por herramientas pequeñas, modulares y combinables, por programas que hacen una cosa bien y por una visión del sistema donde la simplicidad no era un adorno, sino una condición de supervivencia técnica. Esa manera de construir software se asocia hoy a muchos principios de diseño modernos, desde la modularidad hasta la mantenibilidad.
Thompson también diseñó B, un lenguaje descrito por la propia página histórica de Dennis Ritchie como el antecedente inmediato de C. No es un detalle menor: eso significa que Thompson estuvo en el origen de dos de las corrientes más decisivas de la informática de sistemas, el sistema operativo y el lenguaje con el que se reescribió gran parte de ese mundo. Ritchie lo explicó con claridad al hablar del desarrollo de C y de sus ancestros directos.
Décadas después, ya en Google, Thompson volvió a aparecer en otro momento clave. La documentación oficial de Go recuerda que Robert Griesemer, Rob Pike y Ken Thompson empezaron a dar forma al lenguaje en septiembre de 2007, y que en enero de 2008 Thompson ya estaba trabajando en un compilador para explorar ideas. La motivación era similar a la de Unix: construir algo más simple, más legible y más fiable para problemas reales de ingeniería.
Por qué borrar código puede ser más valioso que añadirlo
La frase de las 1.000 líneas tiene sentido precisamente por eso. En desarrollo de software, cada línea nueva no es solo una instrucción: también es una obligación futura. Hay que leerla, entenderla, probarla, mantenerla, protegerla, adaptarla y, llegado el caso, deshacerla. Más código significa, casi siempre, más superficie de error y más posibilidades de que una pieza aparentemente menor complique todo el sistema. La eliminación de código redundante o innecesario reduce ese coste oculto. La propia cultura técnica que rodea a Unix y Go ha insistido durante décadas en esa preferencia por lo esencial.
Eso no implica defender el minimalismo como pose ni glorificar el recorte por el recorte. Borrar código útil, bien probado o necesario puede ser un desastre. La lección de Thompson va por otro lado: la productividad de un ingeniero no debería medirse solo por lo que añade, sino también por su capacidad para entender qué sobra, qué puede simplificarse y qué parte del sistema está imponiendo complejidad innecesaria al resto. Dicho de otra manera, quitar exige comprensión profunda, no pereza.
En una industria dominada durante años por métricas superficiales, esa visión sigue siendo incómoda. Todavía hay organizaciones donde el volumen de commits, la cantidad de funcionalidades entregadas o incluso las líneas de código continúan apareciendo como señales de rendimiento. Pero la experiencia acumulada en los grandes sistemas dice otra cosa: los proyectos sanos suelen ser aquellos donde la arquitectura aguanta, el mantenimiento no se dispara y el código no se convierte en una selva impracticable al cabo de dos años. Y eso rara vez se consigue escribiendo más de lo necesario.
De Unix a Go: la misma obsesión por la claridad
El caso de Go refuerza todavía más esa lectura. En las charlas históricas del proyecto y en la documentación oficial, sus creadores explican que una función o una característica solo se aceptaba cuando los tres diseñadores originales la consideraban necesaria. La idea era evitar “basura adicional”, una expresión que encaja perfectamente con la reputación de Thompson como defensor de los lenguajes y sistemas sobrios. Rob Pike llegó a resumir esa historia recordando que Go nació de la pregunta “cómo debería ser un lenguaje moderno y práctico”, no de la voluntad de acumular todo lo posible.
Esa filosofía también ayuda a entender otra faceta célebre de Thompson: su desconfianza hacia la complejidad excesiva. En entrevistas recordadas durante años, criticó el rumbo de C++ y defendió diseños más contenidos. No es casualidad que el lenguaje Go se presentara desde el principio como una apuesta por la sencillez, la fiabilidad y la eficiencia, tres palabras que, vistas en perspectiva, también sirven para describir buena parte de la herencia cultural de Unix.
La cuestión resulta especialmente actual en plena era de la Inteligencia Artificial aplicada al desarrollo. Hoy es más fácil que nunca generar grandes cantidades de código en poco tiempo. Pero esa facilidad también amplifica un riesgo viejo: confundir velocidad de producción con calidad de ingeniería. Un sistema inflado de líneas innecesarias, dependencias superfluas y capas improvisadas puede nacer más deprisa, sí, pero también convertirse antes en un problema. La frase atribuida a Thompson resiste precisamente por eso: recuerda que la buena programación no consiste solo en construir, sino en decidir qué no merece seguir dentro del sistema.
Al final, la lección del padre de Unix no es romántica ni nostálgica. Es brutalmente práctica. El mejor código no siempre es el más ingenioso ni el más abundante. Muchas veces es el que deja menos ruido, menos puntos frágiles y menos trabajo heredado para el siguiente ingeniero. Y en esa economía de la claridad, borrar 1.000 líneas puede valer más que escribir 10.000.
Preguntas frecuentes
¿Quién fue Ken Thompson y por qué es tan importante?
Ken Thompson es uno de los grandes pioneros de la informática. La ACM le concedió junto a Dennis Ritchie el Premio Turing de 1983 por su trabajo en Unix, y también se le reconoce como diseñador de B, precursor de C, además de ser uno de los creadores originales de Go.
¿Qué significa la frase de borrar 1.000 líneas de código?
La idea refleja que eliminar código innecesario puede ser una forma muy valiosa de productividad. Menos código suele implicar menos complejidad, menos errores potenciales y menos carga de mantenimiento. El Computer History Museum recoge esa cita como una de las más conocidas asociadas a Thompson.
¿Qué relación tuvo Ken Thompson con el lenguaje C?
Thompson diseñó el lenguaje B, que la documentación histórica de Dennis Ritchie identifica como antecedente directo de C. Ritchie desarrolló después C sobre esa base, en estrecha relación con la evolución de Unix.
¿Qué papel tuvo Ken Thompson en Go?
La documentación oficial de Go señala que Robert Griesemer, Rob Pike y Ken Thompson iniciaron el proyecto en 2007, y que Thompson empezó pronto a trabajar en uno de los primeros compiladores para explorar el lenguaje.
