Este artículo, escrito con un tono irónico, explora cómo escribir código deliberadamente difícil de mantener, con el objetivo de generar más trabajo para los programadores que lo heredarán. El autor, Roedy Green, argumenta que siguiendo estas prácticas, uno se asegura una carrera prolongada en el mantenimiento del código creado. La premisa se basa en entender cómo piensa un programador de mantenimiento: busca rapidez, claridad y la capacidad de realizar cambios sin efectos secundarios inesperados. El artículo describe técnicas para frustrar este proceso, creando un código opaco y confuso.
La estrategia central es evitar la transparencia. Esto implica mentir en los comentarios (o mantenerlos desactualizados), usar comentarios triviales en lugar de documentación significativa, y hacer que los métodos hagan más o menos de lo que sus nombres sugieren. Se promueve el uso excesivo de acrónimos no definidos, la eliminación de la encapsulación (exponiendo detalles internos a los llamadores), y la creación de dependencias ocultas que requieren una comprensión profunda de todo el sistema para realizar cambios simples. La técnica del 'cortar, pegar y modificar' se alienta en lugar de la reutilización de código.
Otras tácticas incluyen evitar el uso de variables temporales (empaquetando todo en una sola línea para ahorrar espacio), usar nombres de variables confusos (similares entre sí o con errores ortográficos intencionales), y rechazar herramientas de formateo de código para introducir inconsistencias visuales. La negación de convenciones de nomenclatura estándar de Java, el uso de bucles anidados complejos sin delimitadores {}, y la reutilización de variables con diferentes significados a lo largo del código son también parte de la receta.
En resumen, el artículo es una guía satírica sobre cómo crear un código que sea un dolor de cabeza para cualquiera que tenga que trabajar con él después. Aunque el objetivo es humorístico, subraya la importancia de la legibilidad, la documentación y las buenas prácticas de programación para garantizar la mantenibilidad del código y la productividad a largo plazo. El artículo sirve como una advertencia sobre los peligros de priorizar la eficiencia a corto plazo sobre la calidad del código a largo plazo.