La ventana rota Imprimir
Escrito por edgaragg   
Viernes, 01 de Octubre de 2010 06:07

 

"Una ventana rota, que se queda sin reparar por un tiempo considerable, infunde en los habitantes de edificio una sensación de abandono, una sensación de que no se le presta la atención suficiente al edificio.  Así que otra ventana se rompe, la gente empieza a botar basura, aparecen graffitis, aparecen daños estructurales en el edificio.  En un espacio relativamente corto de tiempo, el edificio se daña más allá del deseo del propietario de repararlo, entonces, el sentido de abandono se hace realidad."

The pragmatic programmer. 

 

De la misma manera, en el desarrollo de software, podemos conseguir "Ventanas rotas", como malos diseños, código pobre o malas decisiones.  Hay que arreglar estas "ventanas" cuando aparecen, y si no es posible, hay que poner un remiendo.  Puedes poner un comentario en el código erróneo, mostrar un mensaje de "no implementado" o "sustituir los datos simulados por los reales", la idea es prevenir daños y demostrar que se está encima de la situación.  Pero ¿qué sucede con las malas decisiones?

Las malas decisiones constituye una ventana rota que hay que corregir con mayor rapidez apenas se detecta.  Una mala decisión o una mala gerencia de proyecto con la que el equipo tiene que convivir es todo lo que se necesita para que el proyecto empiece a declinar, aparezcan más ventanas rotas, y al final el proyecto fracase.  La razón es que la desmotivación del equipo los lleve a pensar que todo lo que hagan a partir de allí no sirve, y como piensa que el código que está escribiendo es basura, pues lo hace sin motivación, por lo que el código basura aparece.  Esto sucede sin importar si el proyecto iba perfectamente hasta ese punto. 

Si un programador empieza a trabajar en un proyecto o en un equipo donde el código está bien hecho (limpio, bien diseñado y elegante) este programador tendrá cierto cuidado de escribir su código de la misma manera y no ser el que estropee el trabajo realizado con un código malo.  Incluso si ocurre un evento inesperado o una urgencia (una fecha límite de entrega, publicación, demo, etc) ese programador no va querer ser el primero en estropear lo hecho.

Por el lado contrario, si este programador trabaja en un equipo donde el código no está bien hecho y/o donde las malas decisiones están a la orden del día, este no se preocupará por escribir un código elegante y bien pensado, se limitará simplemente a hacer lo que le piden sin poner un esfuerzo extra, por lo que siguen apareciendo más ventanas rotas, más graffitis, pronto aparecerán daños estructurales en la aplicación y el costo para corregir todos estos errores será demasiado alto.  El proyecto ha fracasado.

Actualizado ( Viernes, 01 de Octubre de 2010 06:47 )