Untitled Blog Post Name
Hace un tiempo mientras leía el blog Coding Horror descubrí la teoría de la ventana rota, sin animo de ser humilde –vamos, a ver alguien de sistemas que lo sea– puedo resumir esta teoría en la frase “si algo se rompe, pues arréglalo antes que se haga costumbre y se siga rompiendo”

Fuente: lifehacker
Lo primero que debemos saber sobre esta teoría es que tiene ya bastante tiempo y para muchos puede parecer obvia, en mi caso no me pareció tanto así pero me recordó lo que me dijo un amigo mío que es mecánico de autos “si tu carro tiene un raspón, lo mejor es que lo arregles, porque un raspón es de mala suerte, un raspón llama a otro raspón”
Si bien es cierto la frase del mecánico puede parecer un tanto supersticiosa –y la teoría de la ventana rota tiene algo que ver con un auto– personalmente me considero un creyente de la filosofía de no romper/ensuciar las cosas.
Otra manera de comprender como esta filosofía ha trascendido es encontrarte en las calles con algunos letreros o anuncios de “mejor que limpiar es no ensuciar” o quizá algunos baños públicos que aun conserven el “encuéntrame tan limpio como me dejaste”.
Pensando en esto es que recordé a algunos amigos programadores y me pareció interesante notar como esta forma de pensar se ha trasladado de manera inconsciente en muchos de ellos. Estoy seguro que varios dirán “pero es obvio” o “no sabía que se llamaba así” pero tenemos que admitir que hay personas que no tienen la experiencia necesaria para deducir ese tipo de cosas –o acaso naciste sabiendo todo lo que crees saber?–
Habiendo ya extendido esta premisa me gustaría compartir como es que creo que las “ventanas rotas” afectan el mundo del software?
– Evitar “ventanas rotas” va de la mano con el cumplimiento de estándares de programación, esto quiere decir que respetando ciertas reglas de programación tales como nomenclatura de variables o definición de objeto estamos comenzando a crear una casa libre de rajaduras.
– Manejar errores de nuestra aplicación ayudan a evitar aquellas grietas que impiden la identificación de los problemas que se den en tiempo de ejecución. Se dan cuenta que no estoy usando el termino “depuración”? Lo que pasa es que depurar usando el IDE me parece el ultimo recurso para resolver un problema. Acaso no les ha pasado que tienen que poner breakpoints o puntos de interrupción en muchos lugares para saber por donde va el problema? pues eso es lo que debemos evitar!
– Por otro lado, hay muchos programas que sufren el camino de la evolución, pues funcionalmente van respondiendo ante nuevas necesidades pero se van haciendo mas lentas o peor aun, difíciles de usar. Cuando esto pasa con las aplicaciones, de a pocos vamos dejando crecer esas grietas que terminan evolucionando en.. –redoble de tambores– ventanas rotas!
Pero que debemos hacer para evitar lo malo y hacer que se cumpla lo que para mucho es “obvio”? –Por favor noten mis comillas–
Conversando con algunos amigos he llegado a la conclusión de que una solución eficaz se basa principalmente en difundir una cultura de evitar ensuciar, de cumplir buenas prácticas, cumplir estándares, de analizar el impacto ante cada mejora del software que vamos evolucionando, pues no les ha pasado acaso que antes de una mejora todo estaba bien pero luego de actualizar el software las cosas comenzaron a temblar de una forma que te hicieron dudar si debías o no hacer el rollback del ultimo cambio realizado? Pues cada vez que pasa eso, se rompe una ventana.
Lo que no debemos olvidar mis queridos amigos es que todo sistema por mas bueno que sea tiene sus ventanas rotas –escuché Windows Vista? es una broma–, sin ellas no habría emoción, pero que estamos haciendo para irlas arreglando?
Un abrazo.
@jersson,