Los bugs ayudan a los desarrolladores a mejorar, los bugs son las representaciones de los errores de nuestro código. Los niños suelen aprender a andar cayéndose pero intentándolo una y otra vez, aprendiendo a colocar los pies, el peso, etcétera. Las veces que se caen les duele pero ese dolor es el que les dice que no lo han hecho suficientemente bien y que tienen que seguir practicando hasta dominar la técnica.
¿Se puede mejorar sin fallar?
Fallar es la forma natural de aprender, no es que no podamos aprender sin fallar (aunque eso es otra historia). A veces, menospreciamos los bugs, son como la parte mala de la programación. Normalmente los creamos cuando estamos trabajando en alguna feature y no tenemos en cuenta algún caso. Los bugs son consecuencias no deseadas de nuestro código, como cuando los niños se caen intentando andar.
Cuáles son las causas y las consecuencias de los bugs, ¿son realmente malos?
¿Qué provoca que creemos bugs?
He creado montones de bugs en mi carrera de desarrollador, por mi experiencia, las causas por los que aparecen son estos:
- Falta de comunicación con los stakeholders o el Product Owner, no entendí lo que necesitaban.
- Pocos tests.
- Falta de conocimiento de dominio, no comprendía el problema a resolver en su totalidad.
- Demasiadas asunciones sin verificar.
- Sabemos lo que hay que resolver pero no nos dejan o no lo hacemos.
- Accidental complication, el código sobre el que trabajaba estaba en mi contra.
Cada uno de estos problemas mapea con un problema real:
- Falta de comunicación en el equipo, o lenguajes diferentes que provocan malentendidos, entre el Product Owner, los stakeholders y los desarrolladores.
- Falta de conocimiento por mi parte mayormente de dominio pero a veces también técnico.
- Ego muy grande, creo que tengo todas las respuestas.
- Presión por entregar más y más features.
- Procesos muy estrictos que no permiten buscar alternativas a los problemas reales.
- Accidental complication, los mismos problemas expuestos antes pero persistidos en el código por mis predecesores o por mi mismo.
Podríamos deducir que solventando o intentando reducir estos problemas reales podríamos reducir el número de bugs que encontramos, o al menos encontrarlos antes. Pero antes de eso, y ¿por qué nos deben importar los bugs?.
Consecuencias de los bugs
Los costes de un bug dependen de dónde encontremos ese bug:
- Nunca es notificado: el coste durante años puede ser enorme.
- Lo encontramos en producción: el coste dependerá del tiempo que haya estado ahí sin ser corregido.
- Nos damos cuenta en la concepción de la idea: el coste será ridículo.
- Lo encontramos mientras desarrollamos: el coste será pequeño.
Los bugs no son malos, porque nos alertan de que lo hacemos mal. Lo malo son las consecuencias de encontrarlos demasiado tarde. Si encontramos montones de bugs en producción tal vez, deberíamos pensar en cómo estamos trabajando. Los bugs son gritos de tu código alertando que estás haciendo las cosas mal.
Pero los bugs que están en tu código, la deuda técnica que los genera también quedan representados en tu organización. Cuando una empresa tiene muchos bugs intenta eliminarlos tratando de añadir calidad a base de burocracia. Si optamos por ese camino crearemos un problema más grande que el que intentamos solventar.
¿Cómo arreglar un bug?
Cuando nos encontramos con un bug en producción, sentimos ansiedad porque sabemos que está teniendo un coste para el usuario. Esa emoción si nos domina tendrá consecuencias en el código.
He visto montones de desarrolladores, cuando hay un bug en producción, se saltan todos los pasos que normalmente dan al crear features porque les domina la ansiedad.
En mi opinión, ante un bug en producción los pasos que deberíamos seguir serían:
- ¿Cómo de urgente es el bug? ¿Hace perder dinero a la compañía?. Si el bug nos cuesta mucho dinero dejemos todo lo que estamos haciendo y enfoquémonos en el bug. Si no lo es, prioricémoslo como la siguiente tarea a realizar.
- Creemos un test (unitario preferiblemente) que falle debido a nuestro bug, así garantizamos en el futuro que hemos cubierto este fallo.
- Arreglemos el bug, el test debe pasar
- Despleguemos a producción
- Creemos un plan para arreglar el problema real que causó el bug
No deberíamos saltarnos ninguno de estos pasos. Si lo hacemos nos arriesgamos a:
- Introducir más bugs
- Introducir más deuda técnica que causará más bugs parecidos a este
- Aumentamos el coste de mantenimiento de nuestra aplicación
¿Cuándo corregir los bugs?
Si queremos empezar a reducir los bugs que tenemos en producción, lo primero es tratarlos como se merecen. Son más prioritarios que las features, tal vez resolver un bug suponga ganar el doble de dinero para la compañia que añadir una feature nueva. Por tanto, deberíamos priorizar los bugs por encima de las features hasta no tenerlos en producción (Zero Bugs Policy).
Esto no es tan fácil ponerlo en práctica. Como vimos antes, viene provocado por falta de comunicación. Es tremendamente difícil hacer entender a toda la compañía que los bugs y sus porqués son más importantes que las features, la gente que decide sobre el tiempo de los desarrolladores no van a entender que resolver deuda técnica ayudará a reducir bugs en el futuro porque no es fácil medirlo a priori, ni tiene consecuencias directas.
Necesitaremos negociar para tener ese tiempo para resolver los bugs que tenemos y las razones por las que existen, negociar tarea técnica a tarea técnica es inviable (nunca avanzas lo suficiente). Es mejor enfocar esto con tiempo fijo durante la semana (a mí me gusta la figura de batman para esto).
¿Dónde están los bugs?
Según el Principio de Pareto el 80% de los bugs provienen del 20% del código. Podríamos empezar a reducir nuestros bugs mejorando ese 20% del código. Refactoricemos ese código y evitaremos los bugs más frecuentes, podemos conseguir mejorar si escuchamos lo que nos pasa y reaccionamos en consecuencia.
Entonces reducir los bugs es posible, al menos aquellos que se repiten una y otra vez con diferentes formas y ¿sería posible evitarlos todos?
Evitar todos los bugs es imposible (el 20% que falta del principio de Pareto), son inherentes a nuestra condición de humanos. Nuestra alternativa es encontrarlos pronto para que sus costes sean pequeños. Todos los intentos que he conocido por evitar bugs (como regla general) siempre han dado muchos peores resultados que aceptar su existencia y trabajar para encontrarlos antes. La calidad es posible con la velocidad pero debemos evitar generar procesos que bloqueen a los desarrolladores.
Usemos prácticas que nos permitan encontrar bugs antes y nos ayuden a resolver las razones que los crean:
- TDD, encontraremos bugs mientras desarrollamos.
- Pair programming, tendremos feedback de otra persona al momento de escribir el código. Reduciremos nuestro ego, porque tendremos que explicar nuestro código y enfrentarlo con otras ideas. No habrá silos de conocimiento.
- Escribamos las historias junto con nuestro Product Owner, BA, etc (los desarrolladores) para tener un lenguaje común y reducir los malentendidos.
- Tengamos momentos para enseñar nuestro trabajo a otros y recibamos feedback de ellos (desk checks, sprint reviews, demos).
- Continuous Integration, recibamos feedback inmediato cuando intentamos subir nuestro código a master.
- Tengamos tiempo para que el conocimiento se expanda en forma de presentaciones, workshops lo que nos funcione.
- Cualquier otra idea en esta línea, la de mejorar sin bloquear.
Resumiendo, usemos los bugs para crecer como desarrolladores. Seamos mejores cada día, aprendamos más del negocio, hagamos mejor código, intentemos resolver nuestros problemas y no mirar para otro lado.
