Teoría de las ventanas rotas

Las señales visibles de desorden o abandono — como una ventana rota — invitan a más desorden y abandono.

Origen

La formularon los criminólogos James Q. Wilson y George L. Kelling en un artículo en The Atlantic, marzo de 1982, titulado “Broken Windows: The Police and Neighborhood Safety”. La tesis sociológica original era polémica y sigue siéndolo: si en un barrio se rompe una ventana y nadie la arregla, los pocos que se planteaban si valía la pena cuidar ese espacio entienden que a nadie le importa, y la próxima ventana llega antes; el siguiente grafiti, también; el siguiente delito menor, también. La teoría se aplicó (y se sobre-aplicó) en políticas policiales como la del NYPD en los años 90, con resultados muy discutidos por sus efectos colaterales sobre minorías. Esa parte es controversial; la metáfora trasladada al software, en cambio, es mucho menos discutida y muy útil.

Ejemplo: code rot

Andrew Hunt y David Thomas la trasladaron a la ingeniería de software en The Pragmatic Programmer (1999) bajo el nombre “don’t live with broken windows”. La observación: un solo // FIXME ignorado se convierte en diez. Un test que está fallando “desde el martes” sin que nadie lo arregle se convierte en una suite que ya nadie mira. Un warning del linter que el equipo aprende a ignorar se convierte en mil warnings. La codebase se “pudre” no por catástrofes — por señales de abandono que el equipo aprende a normalizar.

El corolario operativo es contraintuitivo: no se trata de perfeccionismo. Se trata de mandar la señal opuesta. Cuando alguien junior ve que el equipo arregla rápido lo que está roto — incluso lo pequeño —, infiere que acá se cuida. Cuando ve // TODO: refactor this in 2019 aún en main en 2026, infiere lo contrario, y se comporta acorde. La cultura de calidad no se enseña en charlas; se enseña en commits.