Gracias al bueno de Carlos Badenes he redescubierto lo que se conoce como "la teoría de las ventanas rotas".
Se trata de un curioso efecto que ya conocía en otras facetas de la vida, aunque gracias a la charla que tuve con Carlos he podido ver que tiene muchas aplicaciones en el mundo de la programación y en el desarrollo de proyectos. A continuación cito una entrada de Fernando Blat donde se explica este concepto con bastante claridad:
A principios de la década de 1980, el politólogo James Q. Wilson se juntó un buen día, puede que incluso soleado, con el criminólogo George Kelling para formular una interesante teoría que justificaría la mismísima guerra preventiva: broken window theory. El principio es muy sencillo, se parte de un edificio en un lugar concreto que se encuentra vacío o sin mantenimiento. En un momento determinado, una ventana aparece rota. Si esta ventana no es reparada o sustituida por otra nueva, pronto aparecerá una segunda ventana rota. Algunas más en poco tiempo. Tras esto, la basura empezará a amontonarse en las puertas de la entrada y en otros lugares del exterior. Una sensación de inseguridad y de abandono que irá en aumento hasta que hacen acto de presencia los primeros merodeadores y vagamundos, incluso algún que otro delincuente de poca monta. Una degradación que terminará atrayendo un foco de delincuencia alrededor del lugar en el que se encuentra el edificio.
Todo se degrada por una ventana rota. Es decir, si se permite una mínima infracción, todo puede terminar degenerándose. Una premisa sencilla y directa que el célebre ex Alcalde de Nueva York puso en práctica. Giulani incluyó esta teoría en su programa electoral y la puso en práctica persiguiendo las transgresiones menores como los grafitos, pequeños hurtos, viajar sin pagar el billete, detener a la gente que se colaba en el metro… Especial relevancia tuvo el último caso. El Alcalde encargó a su jefe de policía, un tal Howard Safir, que detuviese a todas aquellas personas que se colasen en el metro, sobre todo aquellas que lo hicieran de una manera brusca (es decir, corriendo y saltando la valla). Los índices de delincuencia bajaron casi un 40%, dándose la circunstancia de que muchas de estas personas que se colaban en el metro habían cometido un delito antes.
Llegados a este punto me gustaría que tú, estimado compañero de profesión, fueras sincero contigo mismo y, pensando en tu trabajo, te dieses 10 segundos para responder una difícil pregunta que te va a poner en un aprieto:
Fíjate en que no estoy preguntando cuántas había rotas cuando llegaste, ni quién empezó a romperlas, ni tampoco quiero que encuentres el motivo que propició que las rompieras (plazos, cambios de última hora, presiones, etc). Tan sólo quiero que tomes consciencia de que, posiblemente, tú también estás rompiendo ventanas incrementando, por tanto, la tan temida y difícil de pagar deuda técnica.
Piénsalo, medítalo y, cuando acabes, date otros 10 segundos para responder a esta otra dificil pregunta:
Porque es muy sencillo quejarse: "el código no lo entiende nadie", "la documentación no está actualizada", "no hay tests", "los tests no se ejecutan porque no funcionan", "no tenemos claro qué tenemos que hacer", "el código no compila", etc. y más fácil todavía entrar en el círculo de la comodidad y limitarse a cumplir con el "donde fueres, hicieres lo que vieres", rompiendo ventanas.
Pero alguien debe ponerle el cascabel al gato y encargarse de conseguir que el código se entienda, de actualizar la documentación, de hacer tests que funcionen, de preguntar qué hay que hacer, de asegurarse de que el código compile, etc. al menos en la parcela en la cual uno tenga influencia, ¿no te parece?.
No es necesario parar tu actividad diaria para arreglar todas las ventanas rotas que existan a la vez. Por ejemplo puedes ir, en paralelo, documentando aunque sea brevemente aquello que vayas implementando, o haciendo tests que funcionen. Puedes preguntar qué tareas son las que habrá que realizar a medio plazo para anticipar posibles problemas que puedan surgir, o puedes instalar un servidor de integración contínua en tu ordenador y enseñarle a tu equipo lo útil que es. Alguien que se comporta así se convierte en una persona proactiva y en alguien valioso para su entorno. Dame una buena razón por la cual ese alguien no puedas ser tú.
Fijaros si encontrar ventanas rotas es importante que incluso hay metodologías, en concreto SCRUM, que le dedican una fase a su búsqueda y propuesta de soluciones y la llaman retrospectiva.
Ya sabes qué son y cómo identificarlas, así que no tienes excusas ni quejas posibles. La próxima vez que te encuentres frente a un proyecto con ventanas rotas sólo tienes dos opciones: puedes romper otra, haciendo que todo sea un poco peor, o puedes tratar de arreglar alguna, intentando que todo vaya un poco mejor. Tú decides.