Ken Thompson, creador de Unix, se sincera: "Uno de mis días más productivos fue cuando borré 1.000 líneas de código"
¿Medir el éxito por el volumen de trabajo? Ken Thompson, padre y creador de UNIX, explica por qué el verdadero genio de la tecnología consiste en simplificar y destruir lo innecesario.
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.