La filosofía del creador de Unix que desafía cómo medimos la productividad en el desarrollo de software

Uno de los días más productivos de Ken Thompson fue cuando eliminó 1.000 líneas de código. Esa afirmación, que podría sonar paradójica, resume la filosofía que el cocreador de Unix, diseñador del lenguaje B y cocreador de Go ha aplicado durante más de medio siglo construyendo algunas de las piezas más influyentes de la informática moderna: programar bien no es escribir más, sino saber exactamente qué no hace falta escribir.

Quién es Ken Thompson y por qué su visión sobre el código importa

Thompson comenzó a dejar su huella en el software a finales de los años sesenta, cuando junto a Dennis Ritchie desarrolló Unix en los laboratorios Bell. Más que un sistema operativo, Unix fue una forma de entender la computación: herramientas pequeñas, modulares, que hacen una sola cosa bien y se combinan con otras para resolver problemas más complejos.

Esa filosofía de construcción mínima y eficiente se trasladó a cada proyecto posterior. El lenguaje B, que Thompson diseñó como sucesor de BCPL, sentó las bases para que Ritchie desarrollara C, el estándar absoluto de la programación de sistemas durante décadas.

Años 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: claridad por encima de complejidad, sencillez por encima de sofisticación.

Por qué eliminar 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 error, un lugar adicional que debe cubrirse con pruebas y una pieza extra que complica los cambios futuros.

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

En ese contexto, eliminar código no es retroceder: es reducir la superficie de error, simplificar la arquitectura y dejar el sistema en un estado donde los cambios futuros son más rápidos y seguros.

Esa operación exige más criterio que añadir funcionalidad nueva. Obliga a entender el sistema en profundidad, identificar lo que realmente importa y tener el juicio para prescindir del resto, una combinación de habilidades que no se mide en líneas escritas sino en decisiones tomadas.

Cómo Go encarna la filosofía de Thompson

Go nació con la misma obsesión por la claridad que caracterizó a Unix y al lenguaje B. Comparado con lenguajes como C++ o Java, 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 esa lógica: cada elemento que no está en el lenguaje es una complejidad que el programador no tiene que gestionar. Lo que se omite no es una carencia sino una decisión consciente.

Esa filosofía choca de frente con una tendencia extendida 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 ignoran el coste de lo que se acumula, el tiempo que otros equipos necesitan para entender ese código y la fragilidad que genera en el sistema con el paso del tiempo.

Qué es el desarrollo de software

El desarrollo de software es el proceso mediante el cual se diseña, programa, prueba y mantiene un conjunto de instrucciones que le indican a una computadora qué hacer y cómo hacerlo. Esas instrucciones, escritas en lenguajes como Python, Java, C o Go, son las que dan vida a las aplicaciones, los sistemas operativos, las plataformas web y cualquier herramienta digital que se use en el día a día.

El proceso no se limita a escribir código. Incluye etapas como el análisis de los requisitos del sistema, el diseño de la arquitectura, la programación, las pruebas para detectar errores y el mantenimiento continuo una vez que el software está en funcionamiento.

Cada una de esas fases exige decisiones técnicas y de criterio que determinan si el resultado final será un sistema robusto, eficiente y fácil de modificar, o uno frágil que acumula problemas con el paso del tiempo.