Ventanas rotas

On 1 marzo, 2012, in Consejos, Prácticas desarrollo, Sin categoría, by twiindan

Hay una teoría que nacio en los años 1980 por parte de James Q. Wilson y George Kelling que se denomino la teoria de las ventanas rotas con un simple principio:

“Consideren un edificio con una ventana rota. Si la ventana no se repara, los vándalos tenderán a romper unas cuantas ventanas más. Finalmente, quizás hasta irrumpan en el edificio, y si está abandonado, es posible que sea ocupado por ellos o que prendan fuegos adentro.

O consideren una acera o banqueta. Se acumula algo de basura. Pronto, más basura se va acumulando. Eventualmente, la gente comienza a dejar bolsas de basura de restaurantes de comida rápida o a asaltar coches.

Esto responde a una curiosa conducta humana que dice que si algo esta mal ¿ Porque tengo que hacerla yo bien?

Esto es fácilmente aplicable al código de desarrollo y incluso a nuestros diseños de tests o los tests automáticos. Cuantas veces no habremos a alguien quejarse de que ha cogido legacy code que es un desastre y que es muy complicado lidiar con ello. O alguien que haya visto unos tests que de repente fallan y grita a los 4 vientos que están mal realizados o son un desastre?

Ahora preguntaros vosotros cuantas veces hemos hecho algo, hemos pensado que se podría hacer de otra forma mejor pero nos ha dado pereza realizarlo? En ese momento estamos dejando una ventana rota y que puede provocar lo que llamamos deuda técnica (tanto para desarrollo como para test). Cuantas ventanas rotas estamos creando que pueden tener una repercusión en el futuro? Y lo peor de todo cuantas las dejamos aun con la conciencia de que se podrían arreglar? No es más fácil arreglar las cosas cuando son pequeñas que cuando se han acumulado? Esta acumulación suele ser muy peligrosa, ya que después de mucho tiempo cuando se hace inmanejable es cuando alguien piensa cuanto tiempo se tardaría en arreglarlo y te das cuenta que es un tiempo inasumible.

El siguiente punto es… cuantas ventanas rotas hemos arreglado? Como hemos comentado antes es muy sencillo quejarse de que algo esta mal hecho y se pudiera hacer mejor, pero generalmente cuando te encuentras algo mal hecho (por ti o por quien sea), por algún extraño motivo se sigue realizando igual de mal o peor. No estoy diciendo de que digas “a partir de hoy durante 10 días solo voy a arreglar ventanas”, si no que cuando veamos algo que esta mal realizado, y debamos hacer una modificación en esa parte, la arreglemos. Alguien tiene que arreglarlo para que siga siendo mantenible… entonces hay que preguntarse… ¿Porque no yo? Seguro que a la larga, tu y tu equipo lo agradece… no hay nada mejor que predicar con el ejemplo.

 
Para este último caso hay que seguir la regla de los Boy Scouts, “Deje la zona del campamento, incluso más limpia que como  la encontró” o la que solemos encontrar en muchos baños “Deje el baño como le hubiera gustado encontrarlo”. Es decir, si tenemos que tocar algo que hemos realizado anteriormente nosotros o otra persona, en lugar de quejarnos, mejoremoslo, ya que seguro que a largo plazo lo agradeceremos.

 

Tagged with:  

Muchas veces la gente de QA y de Testing juegan al poli malo y mediante metricas, numeros y KPIs “echamos la bronca” (en sentido figurativo) a la gente de desarrollo por realizar más las cosas. Somos especialistas en obtener numeros del Sonar y indicar a la gente de desarrollo que tiene mucho codigo duplicado, que no cumple las reglas del Checkstyle o que no ha documentado suficientemente bien el código.

Nos encanta dar consejos de como deberían programar para ser más efectivos y sacar un software de mejor calidad, nos encanta recomendar algunas buenas prácticas que hemos leido o hemos visto que han funcionado en otros proyectos y por supuesto nos hace felices saber que estamos ayudando cada día a que la gente de desarrollo programe mejor y con más calidad.

Esto creo que es una práctica muy útil que debemos seguir haciendo, ya que ofrecemos un punto de objetividad que quizás dentro del equipo de desarrollo es más complicado de ver. Pero la pregunta es… ¿Porque no nos aplicamos a nosotros mismos las mismas practicas?

Personalmente creo que es muy importante que tratemos nuestro trabajo como si se tratara del de desarrollo. Que quiero decir con esto? Pues principalmente dos puntos:

  • Tratar nuestros diseños o nuestros tests cases como si de código se tratara. Es decir, si vamos a realizar un mismo procedimiento de test con varios juegos de datos, porque no utilizamos una estrategia de DataDriven en lugar de replicar todo el procedimiento? Si como prerequisito dentro de un test case tenemos un procedimiento de un Test Case anterior, porque no lo referenciamos o lo linkamos directamente en lugar de reescribirlo? Realmente es necesario tener TCs de varias hojas o Prerequisitos de más de media página?
  • Tratar los tests automáticos como si se tratara de código fuente. Porque nos resistimos tanto en subirlos a un sistema de versionado? En el caso de que esten automatizados en un lenguaje de programación, también deberíamos pasarles exactamente los mismos procesos de métricas que el código fuente y actuar al respecto. Otro buen ejemplo puede ser crear objetos reutilizables para no crear código duplicado dentro de la automatización.

Que ganamos realmente jugando con otras reglas? Primero de todo, desconfianza de la gente de desarrollo, ya que si algo es bueno, debe ser bueno para todos no solo para algunos. Segundo más trabajo de mantenimiento y tercero provocar que seguir haciendo las cosas mal por nuestro lado.

En mi caso, hace unos 4 mes aproximadamente tuve que realizar cambios en casi todos mis tests automaticos por no haber utilizado elementos reutilizables… por lo que tenia el código duplicado una cantidad innombrable. El resultado, me costo 1 semana entera adaptar los tests automáticos. Eso si aprendi la lección y aproveche que tenía que rehacer más del 60 % de los tests para construir elementos reutilizables para no tener tanto código duplicado. Hace 15 días me volvieron a cambiar una estructura que me hacía fallar el 60 % de los tests aproximadamente. Me costo adaptarlo 4 horas, por lo que tarde un 10 % de la primera vez.

Otro ejemplo práctico, en el tiempo que mi equipo de desarrollo ha realizado tres mini periodos de refactoring (aproximadamente 3 días cada uno de ellos), yo solo he realizado uno a mis tests que no supero un día! Lo que me hace pensar… realmente soy tan bueno que no necesito refactorings? O es que realmente no le doy la suficiente importancia en mis tests a la refactorización?

Esto son solo unos pequeños ejemplos al respecto, ahora también obligo al equipo de desarrollo a que para cerrarme la tarea de la implementación de los tests se asegure que los he subido al sistema de versionado y que tenga una etiqueta, de esta manera tenemos todo un poquito más controlado.

Y vosotros, aplicáis las mismas reglas a la gente de desarrollo que a vosotros mismos? Utilizáis los mismos criterios? Que procedimientos seguis para comprobar la calidad de vuestros tests?

Tagged with: