• El legendario Ken Thompson, creador de Unix y figura clave en la historia de la informática, compartió una reflexión que desafía la obsesión por escribir más código: "Uno de mis días más productivos fue cuando borré 1.000 líneas de código". Esta frase resume una filosofía que va más allá de la programación: la eficiencia no se mide en líneas escritas, sino en soluciones claras y minimalistas.
• Thompson, conocido por su enfoque pragmático, defendía que menos código significa menos errores, menos mantenimiento y mayor claridad. Su "regla de oro" no es solo técnica, sino un principio de diseño que ha influido en generaciones de desarrolladores. La filosofía Unix, que él ayudó a moldear, se basa en herramientas pequeñas, especializadas y que hacen una sola cosa bien, en lugar de sistemas monolíticos y complejos.
• ¿Cómo aplicar esto hoy? Thompson sugiere revisar el código existente y preguntarse: "¿Esto realmente aporta valor o solo añade ruido?". Eliminar lo superfluo no es un paso atrás, sino un avance hacia proyectos más sostenibles y escalables. En un mundo donde la complejidad suele confundirse con progreso, su consejo sigue siendo revolucionario: la productividad no está en lo que añades, sino en lo que te atreves a quitar.

Ken Thompson lleva más de medio siglo construyendo algunas de las piezas más importantes de la informática. Cocreador de Unix, diseñador del lenguaje B (precursor directo de C) y cocreador de Go, ha dejado una huella absoluta en la creación de software que pocos pueden igualar.

Por eso, cuando afirma que uno de sus días más productivos fue cuando eliminó 1.000 líneas de código, vale la pena tomárselo en serio. Afirma que escribir solo lo necesario, eliminar lo que sobra y dejar los sistemas más simples de lo que eran es realmente más productivo.

Quién es Ken Thompson y por qué importa lo que dice

Thompson empezó a marcar la historia del software a finales de los años sesenta, cuando junto a Dennis Ritchie desarrolló Unix en los laboratorios Bell. No fue solo un sistema operativo, fue una forma de entender la computación.

Con herramientas pequeñas, modulares, que hacen una cosa bien y se combinan con otras, adoptó una filosofía de construcción mínima y eficiente que lo acompañó en cada proyecto posterior.

El lenguaje B, que Thompson diseñó como sucesor de BCPL, sentó las bases para que Ritchie desarrollara C, el lenguaje de programación que durante décadas fue el estándar absoluto para la programación de sistemas.

Décadas después, ya en Google, Thompson co‑creó Go, un lenguaje pensado para sistemas de producción a gran escala que repite el mismo patrón: sencillez por encima de sofisticación, claridad por encima de complejidad.

Por qué borrar código puede ser más valioso que escribirlo

Cada línea de código añadida es también una línea que alguien tiene que leer, entender y mantener. Es un punto más donde puede esconderse un bug, un lugar extra que debe cubrirse con pruebas y una pieza adicional que complica los cambios futuros.

Por ello, cuando un sistema crece sin criterio, la deuda técnica se acumula silenciosamente hasta que cualquier modificación, por pequeña que sea, se convierte en una operación de riesgo.

Es por esta razón que, según el experto, eliminar código no es retroceder, sino que es reducir la superficie de error, simplificar la arquitectura y dejar el sistema en un estado en el que los cambios futuros son más rápidos y seguros.

Esa operación exige más criterio que añadir funcionalidad nueva, porque obliga a entender el sistema en profundidad, identificar lo que realmente importa, pero también tener el juicio para prescindir del resto.

La filosofía que heredó Go y que sigue siendo necesaria

Go nació con esa misma obsesión por la claridad comparado con lenguajes como C++ o Java, donde su sintaxis es deliberadamente escueta, su sistema de tipos es directo y sus mecanismos de concurrencia están diseñados para ser entendidos, no solo usados.

Thompson y sus co‑creadores aplicaron en Go exactamente lo que la frase resume: que cada elemento que no está en el lenguaje es una complejidad que el programador no tiene que gestionar.

Esa filosofía choca de frente con una tendencia real en muchos equipos de desarrollo actuales, donde la productividad se sigue midiendo por la cantidad de líneas de código escritas.

Esas métricas son las que ignoran el coste de lo que se acumula, el tiempo que otros equipos necesitan para entender ese código, así como la fragilidad que genera en el sistema.

Ken Thompson lo resumió en una frase, pero es una idea que los mejores ingenieros de software llevan practicando décadas. Programar bien no es escribir más, sino saber exactamente qué no hace falta escribir.