Programming as Theory Building es un ensayo de Peter Naur que propone una perspectiva radical sobre lo que significa真正的programar. Según Naur, el objetivo central del programador no es simplemente producir código fuente, sino construir y mantener una teoría –un modelo mental– del sistema, de sus requisitos y de cómo se relaciona con su entorno. Los artefactos como el código, la documentación o los diagramas son extensiones de esa teoría; lo verdaderamente importante es el conocimiento que el programador guarda en su mente y que puede comunicar a otros.
La idea se puede resumir así: un programa se compone de dos capas. La primera es la teoría interna del programador, que incluye su comprensión de por qué se toman ciertas decisiones de diseño, cómo se mapean los requisitos al código y qué suposiciones se han hecho. La segunda capa son los productos tangibles –código, pruebas, comentarios, diagramas– que tratan de reflejar esa teoría para que otros puedan reconstruirla. Cuando se trabaja de esta manera, actividades que normalmente se tratan por separado (escribir código limpio, crear documentación, realizar pruebas automatizadas, aplicar patrones de diseño o Domain‑Driven Design) cobran un propósito unificado: comunicar y preservar la teoría del programa.
Esta visión tiene implicaciones prácticas concretas. Si un desarrollador modifica código sin haber captado la teoría subyacente, los cambios tienden a ser “hacky” y difícil de mantener. Del mismo modo, evaluar la viabilidad de una nueva funcionalidad requiere tener un modelo mental del sistema; sin él, la estimación se basa en suposiciones vagas. Por otro lado, herramientas como patrones de diseño o DDD no son solo recetas técnicas, sino vehículos que facilitan la transmisión del conocimiento entre miembros del equipo, reducen la barrera de entrada para nuevos desarrolladores y hacen que el sistema sea más predecible.
No obstante, la teoría de Naur también invita a considerar algunas dificultades. Construir y mantener una teoría mental es intangible y requiere tiempo; no siempre se puede medir ni formalizar fácilmente. Equipos con alta rotación o con cultura de “escribir código y ya” pueden tener problemas para preservar esa comprensión. Como alternativa o complemento, prácticas como revisiones de código, documentación viva, sesiones de pair programming y modelado explícito del dominio ayudan a externalizar la teoría y hacerla accesible a todos.
En definitiva, “Programming as Theory Building” ofrece un marco conceptual que unifica las buenas prácticas de desarrollo de software bajo un solo objetivo: asegurar que el conocimiento sobre el sistema se construya, se conserve y se comparta activamente. Leer el ensayo original de Naur es muy recomendable para cualquier desarrollador que busque entender por qué escribir software mantenible es tan difícil y cómo superarlo.