No lo tocas, pero se pudre igual. La segunda ley de la termodinámica también aplica a tu código, y no es una metáfora — es una condena estadística. Te explico por qué con ventanas rotas, leyes de Lehman y un demonio que no es Maxwell sino tu yo del pasado.
El código que no tocas también muere
Hay un fenómeno que todo developer ha vivido pero pocos saben nombrar. Abres un repo que no visitabas hace seis meses. El código es tuyo. Tú lo escribiste. Pero algo ha cambiado. Las dependencias están outdated, los tests ya no corren, y esa abstracción tan elegante que diseñaste ahora parece un jeroglífico. No lo tocó nadie. Y sin embargo, envejeció.
Esto no es una sensación. No es mala suerte. Es física.
Bienvenido a la entropía del software.
La segunda ley (sí, esa)
Vamos a hacer un pacto: te prometo que esto no se va a convertir en una clase de termodinámica. Pero necesito que entiendas una cosa, y es probablemente la idea más subestimada en la historia del desarrollo de software.
La segunda ley de la termodinámica dice que en un sistema aislado, la entropía —el desorden— siempre aumenta. Siempre. No es una opinión. No es una tendencia. Es una certeza estadística tan brutal que si la violas, es más probable que te caiga un rayo mientras te toca la lotería.
¿Por qué? Porque hay abrumadoramente más formas de estar desordenado que ordenado.
Piensa en tu habitación. Hay exactamente una forma de que esté perfectamente ordenada. Pero hay millones de formas de que esté hecha un desastre: la camiseta en la silla, el cargador en el suelo, el libro abierto bocabajo en la mesita. El desorden no requiere explicación —es el estado natural de las cosas. El orden requiere trabajo.
Tu código funciona exactamente igual.
La teoría de las ventanas rotas
En 1982, dos criminólogos —Wilson y Kelling— publicaron un paper que cambiaría la política urbana para siempre. Su tesis: una ventana rota en un edificio, si no se repara, invita a romper todas las demás. No porque la gente sea mala. Sino porque una ventana rota comunica que aquí nadie cuida esto.
Andrew Hunt y David Thomas, en The Pragmatic Programmer (1999), tomaron esta idea y la insertaron quirúrgicamente en el desarrollo de software. La llamaron Software Entropy.
"No dejes ventanas rotas sin reparar. Si encuentras código mal diseñado, decisiones equivocadas o malas prácticas, arréglalas ahora. Cada ventana rota que se deja sin reparar consolida el deterioro del sistema."
¿Qué es una ventana rota en código?
- Una variable mal nombrada que copias "porque total, luego la cambio"
- Un test que falla y comentas con
# TODO: fix later - Un
ifanidado a tres niveles "temporal" que lleva dos años en producción - Un comentario que miente sobre lo que hace la función
- Una dependencia que sabes que está deprecated pero "funciona"
Cada una, por sí sola, es inofensiva. El problema es lo que comunican al siguiente developer (que probablemente eres tú dentro de tres semanas): "Aquí el estándar ya está roto. Relájate."
Y así, commit a commit, el desorden crece.
Las 8 leyes de Lehman (o "cómo la academia te dijo esto en 1974 y no le hiciste caso")
Meir M. Lehman pasó más de 20 años estudiando cómo evolucionan los sistemas de software reales —empezando por el OS/360 de IBM, un monstruo de su época—. Formuló 8 leyes. Aquí van las tres que te van a doler:
Ley 1 — Cambio Continuo (1974)
Un sistema que se usa debe cambiar continuamente, o se vuelve progresivamente menos satisfactorio.
Tu software no existe en el vacío. El mundo cambia: nuevas regulaciones, nuevas APIs, nuevas expectativas de los usuarios. Si tu código no se adapta, muere. Así de simple.
Ley 2 — Complejidad Creciente (1974)
A medida que un sistema evoluciona, su complejidad aumenta a menos que se realice trabajo explícito para mantenerla o reducirla.
Esta es la ley de la entropía del software con nombre y apellido. Cada feature que añades, cada fix que metes, cada dependencia que actualizas aumenta la complejidad del sistema. No importa lo buen developer que seas: no existe el cambio perfecto. Sin refactorización explícita, el sistema se vuelve más difícil de entender, modificar y extender. Incluso en equipos excelentes.
Ley 7 — Calidad Decreciente (1996)
La calidad de un sistema parecerá declinar a menos que sea rigurosamente mantenido y adaptado a cambios en su entorno.
Esto es brutal: aunque no toques el código, la calidad percibida baja. Porque el entorno cambia. Nuevas versiones del sistema operativo. Nuevas vulnerabilidades de seguridad. Nuevos estándares de UX que hacen que tu app de 2020 se vea como una reliquia. Lo que antes era "rápido" ahora es "lento". Lo que antes era "seguro" ahora tiene un CVE.
Débito técnico: la factura que siempre llega
Ward Cunningham acuñó el término technical debt en 1992, y su analogía es perfecta:
"Entregar código imperfecto para llegar a una fecha límite es como tomar una deuda financiera. Pagas intereses en forma de tiempo extra en el futuro."
La conexión con la entropía es directa y medible:
| Concepto físico | Su análogo en software |
|---|---|
| Entropía | Complejidad del código (acoplamiento, falta de cohesión) |
| Energía para ordenar | Refactorización, code review, tests |
| Incremento sin intervención | Débito técnico acumulado |
| Equilibrio termodinámico | Sistema legacy inmantenible |
Cada vez que un developer se encuentra un TODO de hace tres años, una abstracción que filtra responsabilidades, o una función de 400 líneas sin documentar, está pagando intereses. Y el interés compuesto en software es igual de despiadado que en finanzas.
El ciclo de la muerte (y cómo romperlo)
Así es como la entropía se come tu proyecto, paso a paso:
El mundo cambia → Nuevos requisitos
↓
Código nuevo se añade (sin refactorizar)
↓
Complejidad ↑ + Calidad ↓
↓
Más presión por entregar → Más atajos
↓
Velocidad de desarrollo ↓
↓
Sistema legacy ☠️
Este ciclo no es un accidente. Es la manifestación de las Leyes 1, 2 y 7 de Lehman operando juntas. Y la única forma de romperlo es con trabajo explícito, continuo y disciplinado.
Cómo combatir la entropía (las herramientas que funcionan)
No hay bala de plata. Pero hay estrategias que la evidencia respalda:
1. Refactorización como hábito, no como proyecto
No "sprint de refactorización". No "vamos a limpiar el código en enero". Refactorización en cada commit, como quien tiende la cama cada mañana. Pequeña, constante, invisible.
2. Tests que te dejen dormir
La refactorización sin tests es parkour sin red. Los tests automatizados son lo único que te permite reorganizar el código con la certeza de que no estás rompiendo nada. Sin tests, la entropía gana por inacción —no refactorizas porque tienes miedo.
3. Code review como firewall cultural
Cada PR es una oportunidad para detectar ventanas rotas antes de que se fusionen. El code review no es para pillar errores —es para mantener el estándar de calidad colectivo. Si el equipo tolera atajos, la entropía acelera.
4. CI/CD como sistema de retroalimentación
La Ley 8 de Lehman dice que los sistemas de software son sistemas de retroalimentación multinivel. Un pipeline de CI que corre tests, linter, y checks de seguridad en cada push es tu sistema inmunológico. Sin él, el código se desvía irreversiblemente.
5. Abstracciones con fecha de caducidad
Toda abstracción elegante que nadie mantiene se degrada. Las abstracciones no son monumentos —son herramientas vivas. Si no tienes a alguien que entienda y defienda esa abstracción, se convertirá en deuda técnica con piel de cordero.
6. La regla del boy scout
"Deja el código mejor de como lo encontraste."
No necesitas refactorizar 2000 líneas. Con renombrar una variable confusa, extraer una función de 50 líneas en dos de 25, o borrar un comentario obsoleto, ya estás empujando contra la flecha del tiempo.
La paradoja del software exitoso
Y aquí viene la ironía suprema:
El software más exitoso es el que más envejece.
Un proyecto que nadie usa permanece "perfecto" para siempre. Un sistema con miles de usuarios evoluciona constantemente, y en esa evolución inevitablemente acumula entropía. Linux lleva 30+ años vivo. No es perfecto. Pero tiene procesos, mantenedores, jerarquías y una cultura que valora la calidad tanto como las nuevas funcionalidades.
La entropía no se elimina. Se gestiona.
La única pregunta que importa
No existe el software que "se mantiene solo". No existe el código que envejece con gracia sin intervención. La física no negocia.
La única pregunta es esta:
¿Cuánta energía estás dispuesto a invertir para mantener el orden?
Porque el desorden es gratis, automático y silencioso. El orden requiere trabajo, cada día, sin excepción. Como tender la cama. Como lavar los platos. Como cualquier sistema que quieras mantener habitable.
Tu código no es especial. También obedece la segunda ley.
"Programs, like people, get old. They grow rigid, fragile, and eventually die. The difference is that programs, unlike people, can be kept alive indefinitely by constant care and feeding."
— M. M. Lehman
Para seguir leyendo
- Hunt & Thomas — The Pragmatic Programmer (1999, 20th Anniversary Edition 2019). El capítulo sobre Software Entropy es de lectura obligatoria.
- Lehman, M. M. et al. — Metrics and Laws of Software Evolution — The Nineties View (1997). Las 8 leyes con datos reales.
- W. Cunningham — The WyCash Portfolio Management System (OOPSLA '92). Donde nació el concepto de technical debt.
- Shannon, C. E. — A Mathematical Theory of Communication (1948). Para los que quieran entender H = −Σ p log p desde la fuente.
Top comments (1)
Gracias, ¡fue una buena lectura!
Este es el punto que los desarrolladores sénior suelen pasar por alto al crear un framework.
Lo construyen y luego dejan que se deteriore.
Seo puing inntinneach air a bheil mi air a bhith a’ bruidhinn o chionn bhliadhnaichean: tha deasaichean aig filmichean. Tha feum againn-ne air deasaichean cuideachd.
Saoil air Star Wars. Bha lèirsinn mhòr aig Lucas agus mar sin air adhart, ach cha b’ urrainn dha am film a dheasachadh, oir bha gaol aige air – mar a b’ àbhaist.
Ach bha Lucas glic, agus dh'fhastaidh e cuideigin a rinn deasachadh air an fhilm. Agus 's e seo an Star Wars a tha sinn dèidheil air. An dreach a chaidh a ghearradh agus a dheasachadh.