El coste de un bug

bicho-bugCuando se desarrolla software se comenten errores (bugs), esto forma parte del trabajo. Cada uno de estos errores tiene un coste, normalmente cuando más tarde se detecta, más caro nos cuesta solucionarlo.

Estos son algunos de los momentos en los que la empresa puede detectar y solucionar estos errores :

  1. En el propio desarrollador
    Un buen desarrollador con años de experiencia comete menos errores, el código que realiza se protege de los bugs. Estos programadores cobran más, pero su código es más fiable.
  2. En la integración continua
    Dentro de la integración continua se pueden usar diferentes sistemas para detectar bugs ( Pruebas unitarias, pruebas funcionales, análisis estáticos de código, etc )
    Dentro de la integración continua es muy útil tener automatizadas todas estas pruebas automáticas que detectan fallos de desarrollo y nos da garantías de que los cambios subidos no rompen nada.
    Coste*: 1 hora del desarrollador ver el log y arreglar el problema 
  3. En el equipo de desarrollo
    Ya sea por revisión por pares o por programación por parejas, se pueden detectar los bugs antes de que el código salga del departamento de desarrollo.
    Coste*: 2 h. del desarrollador que encuentra el problema y de quien lo soluciona 
  4. En el departamento de pruebas
    Si el error llega hasta el departamento de pruebas, este equipo tiene que ocuparse de detectarlo y entender como ocurre y como hacerlo reproducible. Otro elemento importante es describirlo al desarrollador que suele ser un punto de conflicto,  la comunicación debe ser muy eficaz para que el desarrollador pueda entenderlo y solucionarlo.
    Coste*:  1h. para encontrarlo y documentarlo + 1 h. en entenderlo + 1 h. para solucionarlo 
  5. Los betatesters
    Si el bug no se ha encontrado dentro de los equipos de desarrollo y pruebas, el producto con el error llega al betatester que si lo encuentra, deberá comunicarlo al departamento de pruebas, la solución a este bug debe pasar por varios departamentos e incurre en trabajo de mucha gente.
    Por otro lado, la solución al error, puede romper otro elemento, con lo que esa versión debe pasar de nuevo todas las fases previas.
    Coste*: 1h. del betatester + 1 h. para encontrarlo y documentarlo + 1 hora en entenderlo + 1 hora en solucionarlo 
  6. El usuario final
    Si el bug llega al usuario se sentirá frustrado porque la nueva versión no hace lo que debe. Del mismo modo quizá no informe correctamente al equipo. Si lo hace, debemos tener un canal por el equipo de soporte para ello. Este tipo de bugs generan mucho trabajo y mala imagen, incluso en ocasiones pueden generar un parche, con el enorme coste que esto provoca.
    Coste*: 1 h. del cliente final + 1 h. persona de soporte + 1 hora persona de pruebas + 1 h. para entenderlo + 1 h. solucionarlo 

Sacar un parche para muchos clientes no tiene precio 😉

*Coste: Es un tiempo medio, cada error es un mundo, unos se solucionan en minutos y otros en días.

Revisión por pares

Como bien comenta jgarzas, en su post Beneficios del pair programming, que dos desarrolladores compartan el editor y hagan el desarrollo de forma conjunta puede aportar un plus de calidad a nuestro proyecto.

Del mismo modo, la puesta en marcha es complicada, por la sensación de pérdida de productividad.

Hace tiempo pusimos en práctica la revisión por pares, consiste en definir unos pares de desarrolladores donde cada uno verá el trabajo realizado por su compañero el día anterior.

Un script nocturno en la herramienta de integración continua captura del control de cambios el resumen de las modificaciones realizadas el día anterior por su compañero. Con la información se compone un email y se envía a cada par correspondiente.

El desarrollador lo primero que hace en el día es ver y entender lo que ha realizado su compañero, ante cualquier duda respecto al código, al formato o los comentarios, el desarrollador le consulta a su par e inician un diálogo para aclarar dudas.

Con la revisión por pares conseguimos una serie de beneficios:

  • Aprendizaje de trucos y el buen hacer de los compañeros
  • Amplio conocimiento de todo el proyecto
  • Solución a problemas de estilo de código
  • Solución a problemas de código detectado por un compañero
  • Unificación de criterios en la forma de desarrollar

No es tan eficaz como la programación por pares, pero ayuda al trabajo en equipo.

Es llevar a la práctica la ley de Linus en un equipo de desarrollo de una forma que no invertimos mucho tiempo en la revisión.

Lo que el cliente no pide, pero exige

En desarrollo de software es habitual que los usuarios pidan más y más funcionalidades, si fuera por ellos una aplicación crecería en “sus” funcionalidades hasta el infinito.

Pero por otro lado el cliente asume que la aplicación será rápida, estable y segura, pero eso no se suele pedir, se asume que es así.

Muchos de los trabajos relacionados con la calidad de tu software, son trabajos ocultos para el usuario, pero que son igual o más importantes que añadir más funcionalidad.

Es labor de todo el equipo dedicarle tiempo a la calidad del producto, ya que llegado un momento nuestra deuda técnica es tan grande que empezamos a sufrir distintos problemas relacionados con la falta de calidad.

Todos estos trabajos relacionados con añadir más calidad a nuestro producto deben ir incluidos en cada una de nuestras iteraciones, no debe ser un trabajo puntual cuando las cosas vayan mal.

Guias de estilo en los equipos de desarrollo

Cuando desarrollamos un producto o proyecto en equipo es interesante que existan unos criterios mínimos comunes entre todos para que nuestro código y proyectos sean lo más homogéneos posibles. Con ello conseguimos importantes beneficios

  • Mantenibilidad del proyecto
  • Evitar código spaguetti
  • Optimización de recursos evitando repetir el mismo trabajo
  • Mejor lectura del trabajo por parte de todos
  • Evitar conflictos entre los desarrolladores

El hito más importante es conseguir que ningún desarrollador reconozca su trabajo entre el de sus compañeros en base al estilo personal de cada uno.

Cada persona tiene su “guía de estilo” personal que va cambiando a lo largo del tiempo y la experiencia. Debemos conseguir tener una “guía de estilo” común para el equipo y que vaya mejorando a lo largo del tiempo.

Guía de Python
Google C++ Style Guide
Guía de Velneo vDiseño

Kevin Kelly sobre la evolución de la tecnología

Interesante presentación de Kevin Kelly sobre la evolución de la tecnología.

En esta presentación compara la evolución de la vida en la tierra con la tecnología.

La pregunta a responder : ¿A que aspira la tecnología?

Checklist para un cambio tecnológico en la empresa

En las empresas suele ser habitual tener que hacer todo tipo de cambios para adaptarse a las diferentes situaciones. En especial los cambios de herramientas tecnológicas.
Lo más importante es saber en todo momento que es un cambio que afecta a personas y que en muchas ocasiones poco importa lo bueno o lo mala que sea la herramienta. La palabra clave para el cambio se llama comunicación. Es necesaria mucha comunicación, es mejor en exceso que en defecto.

Por la experiencia de los últimos cambios tecnológicos en los que he estado involucrado he creado este checklist

1. Conocer la nueva herramienta y probarla

Es importante tener claro que la nueva herramienta es la más adecuada para la empresa y deberemos hacer las pruebas necesarias para no tener sorpresas de última hora.

2. Conocer las fortalezas y debilidades de la herramienta que vamos a sustituir

Debemos conocer la herramienta que vamos a sustituir o el proceso que vamos a quitar. Todo lo que desconozcas de ella podrá ser utilizado en tu contra 😉

3. Comunicar las intenciones y las motivaciones del cambio

A las personas les gusta conocer los porqués, si se hace el cambio es por algún motivo. Esta fase es muy importante ya que es donde ganamos aliados

4. Aclarar dudas con los detractores y personas clave

Siempre tendrás personas con dudas, que no les gusta el cambio. Algunas estarán molestas porque no les consultaste o porque se enteran a última hora. Es importante hablar con todos ellos y que se sientan escuchados. En muchos casos te aportarán información importante que no has tenido en cuenta.

5. Formación a todos

La formación es la excusa perfecta para que todos se imaginen el cambio. El primer paso para aceptar un cambio es imaginarte a ti mismo con el cambio realizado. La formación nos ayuda a sacar a las personas del día a día para que se puedan imaginar una vez realizado el cambio.

6. Comunicar que ya queda poco y que estarás personalmente para ayudar

A todo el mundo le gusta saber que estarás allí y que si hay problemas podrás ser totalmente accesible. Es importante transmitir seguridad. Serás el socorrista de la piscina, no importa si sabes nadar o no, lo importante es que estés atento.

7. Cambio gradual

Siempre que puedas busca la posibilidad de implantar la nueva herramienta de forma gradual, primero 2 usuarios, luego 10,  luego 100. Siempre salen detalles o elementos no previstos que puedes ir solucionando tranquilamente cuando el cambio afecta a pocos usuarios

8. Pedir confirmación de que el cambio ha ido bien y si hay algún detalle pendiente

Algún usuario puede estar mal a gusto con el cambio y no transmitirlo directamente, suele ser muy efectivo pedir confirmación del cambio y enterarte de los pequeños flecos que puedan quedar.