La valla de Chesterton: una lección de pensamiento de segundo orden (2021)
La valla de Chesterton —la idea de que no deberías retirar una norma, costumbre o sistema existente hasta entender por qué se puso ahí— se examina como una herramienta de “pensamiento de segundo orden” y una fuente de tensión entre prudencia y progreso. Los comentaristas contrastan su valor para prevenir daños invisibles en sistemas evolucionados (leyes, tabúes sociales, software heredado) con la forma en que puede fosilizar instituciones, justificar no refactorizar ni reformar nunca y convertirse en un cliché que detiene el pensamiento. Muchos argumentan que la respuesta práctica está en la investigación, la experimentación y una mejor documentación de por qué se construyen las “vallas” en primer lugar, en vez de caer por defecto ni en la disrupción ciega ni en el conservadurismo ciego.
Interpretación central de la valla de Chesterton
- Muchos destacan que el principio no es “nunca quites las vallas”, sino “entiende por qué existen antes de cambiarlas”.
- Se plantea como un argumento a favor de la curiosidad y la investigación profunda, no de un conservadurismo generalizado.
- Varios señalan que encaja con ideas como el efecto Lindy y con el estudio de la historia: las instituciones longevas probablemente codifican adaptaciones ganadas con esfuerzo.
Críticas: cliché que termina el pensamiento e inercia
- Algunos sostienen que a menudo se convierte en un movimiento “que detiene el pensamiento” en política y organizaciones, usado para bloquear reformas indefinidamente.
- Los críticos dicen que los “criterios para retirar” pueden ser imposibles en la práctica: las justificaciones se pierden, son contradictorias o políticas.
- Otros responden que es una heurística, no una exigencia de certeza al 100%; “la valla fue un error” es una conclusión válida tras una investigación razonable.
Ejemplos de ingeniería y software
- Analogía común: código heredado, configuraciones y reglas de negocio.
- Los defensores describen “pagar el impuesto de Chesterton”: rastrear la historia antes de limpiar o refactorizar, a veces descubriendo casos límite reales.
- Otros señalan que el miedo a romper cosas desconocidas puede congelar la refactorización, especialmente cuando nadie entiende el código pero el riesgo de fallo es alto.
- Mitigaciones sugeridas: reescrituras en paralelo, banderas de funciones / “scream tests”, pruebas intensivas en lugar de pura arqueología histórica.
Documentación, proceso y carga de la prueba
- Tema fuerte: la verdadera solución es documentar por qué se construyen las “vallas”, para que futuras retiradas estén informadas y sean baratas.
- Algunos argumentan que las vallas sin justificación documentada deberían eliminarse por defecto, empujando a los constructores a registrar sus razones.
- Otros responden que en ámbitos de alto riesgo (ley, sociedad) las consecuencias pueden ser tardías y graves, así que la eliminación por defecto es peligrosa.
Riesgo, experimentación y contexto
- Varios distinguen entre startups y software de movimiento rápido (donde los fallos temporales son aceptables) y sociedades y regulaciones (donde los fallos pueden ser catastróficos).
- Algunos abogan por una cultura de experimentación frecuente: múltiples empresas o estados probando variantes “sin vallas” y aprendiendo de los resultados.
- Otros subrayan que una alta adaptabilidad mediante desmontaje constante puede venir con una alta “mortalidad”, aceptable para empresas pero no obviamente para sociedades.
Extensiones más allá de los sistemas
- Aplicado a tabúes sociales, normas culturales, fisiología y hábitos personales.
- Para las “vallas” psicológicas internas, algunos sugieren que el cambio puede preceder a la comprensión; de otro modo, la parálisis por análisis puede impedir el crecimiento.