El 22 de junio de 2026, Martin Tournoij (arp242) publicó un breve artículo cuyo título cambiaba una sola letra del principio clásico — Fence (valla) se convirtió en Finger (dedo). Detrás de este juego de palabras hay un escenario real de desastre en ingeniería de software. Lo contrataron para hacerse cargo de un código base con 13 años de antigüedad; todos los que estaban antes que él se habían ido. El git log contenía un total de 295 líneas de mensajes de commit; tras eliminar los commits automáticos de dependabot y los «fix typo», solo quedaban 167 líneas, un promedio de una por mes. Sin documentos de diseño, sin comentarios en el código. Restos de refactorizaciones incompletas, vestigios de funcionalidades eliminadas, y características completamente implementadas pero nunca referenciadas por ninguna página.
Tournoij lo llama el dedo medio de Chesterton. «Sí, hicimos todas estas cosas extrañas, y no pensamos contarle a nadie por qué. Jaja, que te jodan.»
La Valla de Chesterton (Chesterton’s Fence) es un principio de la obra de G.K. Chesterton de 1929, The Thing. La fábula es simple: un reformador ve una valla atravesada en medio de un camino, le parece inútil y quiere derribarla. Chesterton dice: no te apresures a derribarla — primero debes entender por qué se construyó. Tal vez la razón por la que se construyó aún no la ves, pero esa razón existió. Este principio ha sido citado repetidamente por la comunidad de ingeniería de software porque acierta precisamente en un escenario de alta frecuencia: alguien elimina un fragmento de código que «parecía inútil», y meses después la producción falla porque ese código manejaba una condición límite que solo se desencadena una vez cada tres años. Nadie sabe por qué estaba allí, porque quien lo escribió se fue hace dos años.
arp242 no cambió Fence por Finger como una simple ocurrencia. El problema del código base que experimentó Tournoij no es que el código estuviera mal escrito — el código malo está en todas partes. El problema es que nadie dejó ningún registro sobre el «por qué». 13 años de decisiones acumuladas, todas las compensaciones, todas las restricciones históricas, todos los errores aprendidos, completamente evaporados. La persona que hereda el código no está «saltando una valla» — una valla al menos tiene una presencia física visible que sugiere «aquí alguien tomó una decisión». Él se enfrenta a un vacío de información total. Esto es mucho peor que una valla. Una valla es un recordatorio silencioso; un dedo medio es una burla silenciosa.
Esta distinción toca el valor central de los comentarios en el código. El código en sí mismo ya dice «qué hace» — siempre que el lenguaje no sea deliberadamente ofuscado, la lógica se puede leer. Pero el código nunca puede decir «por qué se eligió la opción A en lugar de la opción B». Ese workaround extraño era porque una versión de una librería tenía un bug; esa comprobación de null aparentemente redundante era por un incidente P0 un viernes por la tarde de 2019; esa lógica de ordenación extraña era porque el sistema downstream tenía una dependencia rígida del orden, y esa dependencia era en sí misma un error histórico. Esta información, si no está en los comentarios o en los mensajes de commit, se pierde para siempre. La pregunta de Tournoij es directa: escribir esto no es trabajo adicional opcional, es parte del trabajo de desarrollo. No importa si está mal escrito, no importa si el inglés no es bueno, no importa si se olvidan algunos detalles, pero al menos debe haber «algo». No tener nada es mostrar el dedo medio a todos los que vienen después.
En la discusión de Lobsters, un comentario de ChrisDenton (18 votos) llevó el tema al nivel organizacional. Señaló un dilema más sutil: a veces, en el momento, nadie sabe qué información será importante en el futuro. Si la discusión en torno a una decisión no se registra — ya sea en correos, chats o issues — la «arqueología digital» posterior es casi imposible. Y cuando una organización trata a los desarrolladores como piezas intercambiables, esta vulnerabilidad se amplifica al extremo. Nadie se queda el tiempo suficiente, nadie acumula una intuición holística del sistema, los mismos errores se cometen una y otra vez, y reinventar la rueda se convierte en la norma. La redacción de ChrisDenton es mesurada, pero su conclusión es incisiva: las organizaciones que tratan a los desarrolladores como piezas intercambiables son las más frágiles.
david_chisnall (8 votos) añadió una puntada desde la perspectiva de la revisión de código (code review). Dijo que el mayor valor del code review es obligarte a añadir comentarios a las decisiones no obvias — encontrar bugs es un subproducto. El mayor valor es que «la segunda persona te obliga a añadir comentarios a las decisiones no obvias». Él mismo escribe comentarios para aquellas cosas que le parecen poco evidentes. El revisor pregunta por lo que le parece poco evidente. Después de dos rondas, los comentarios cubren lo que dos personas consideran que necesita explicación. Cuando alguien después lee ese código, la probabilidad de entenderlo ya no es cero. La sutileza de este mecanismo es que no depende de la autoconciencia del autor — integra la retención de conocimiento en un proceso que no se puede eludir.
¿Pero deberían conservarse todas las vallas? También hay un lado opuesto. Steph Tulkens escribió un artículo titulado «Chesterton’s Gap» — la valla aún no se ha construido, primero hay que construirla. El exceso de conservadurismo también es dañino: todos los equipos conocen ese código heredado que nadie se atreve a tocar, cuya lógica circundante ya ha cambiado tres veces, y el problema que ese código manejaba originalmente probablemente ya no existe, pero como «no se sabe por qué se escribió», se mantiene. La deuda técnica no solo se acumula por modificar código incorrectamente, no atreverse a modificar código también acumula deuda técnica. ¿Cuándo derribar una valla y cuándo mantenerla? No hay un algoritmo que pueda decidirlo automáticamente. El criterio solo puede venir de una comprensión suficientemente profunda del sistema — lo que precisamente nos devuelve al argumento de ChrisDenton: si la organización trata a los desarrolladores como piezas reemplazables, ni siquiera se puede cultivar ese criterio.
A continuación se presenta un marco de decisión simplificado, en forma de lista de preguntas:
| Dimensión | Tendencia a conservar | Tendencia a eliminar |
|---|---|---|
| Disponibilidad de contexto | El equipo original se ha ido, sin documentos ni comentarios | El decisor original aún está, se puede preguntar directamente |
| Alcance del impacto del cambio | Afecta rutas críticas de negocio, errores con consecuencias graves | Módulo aislado, con cobertura completa de pruebas |
| Claridad de la intención del código | Hay comentarios explicando el «por qué», lógica coherente | Los comentarios dicen «qué hace» y no coinciden con el comportamiento del código |
| Frecuencia de activación | Maneja condiciones límite de baja frecuencia pero alto impacto | El código nunca se ha ejecutado |
| Costo de reemplazo | Reescribir requiere redescubrir todas las condiciones límite | Hay una especificación clara para guiar la reescritura |
Esta tabla no resuelve ningún problema. Solo recuerda: decidir si hay que derribar una valla requiere más información que derribarla misma.
El artículo de Tournoij obtuvo 82 votos en Lobsters, no porque dijera algo nuevo. La Valla de Chesterton se ha discutido en el ámbito de la ingeniería de software durante más de una década. La resonancia viene de la emoción que nombró: escribir código malo no es necesariamente malicioso, pero irse sin dejar una sola explicación es un desprecio hacia todos los que vienen después. Cada desarrollador que ha sido despertado a las tres de la madrugada por «ese código heredado incomprensible» reconoce ese dedo medio. Repararlo no requiere más procesos normativos, solo tratar el mensaje de commit como parte del producto final. Esos 167 commits en 13 años — ese número en sí mismo es el argumento más efectivo.