Release or not release, that is the question!

Un interesante dilema que se plantea a diario en el desarrollo de software:

• oportunidad versus perfección
• implementar versus seguir probando
• ser primeros versus cero errores

Estas son algunas de las contradicciones que trae como consecuencia el dilema "release or not release" y que generan mayor o menor tensión según la industria para la cual desarrollamos.

Una balanza podría ser una buena representación gráfica de este dilema. Balanza que observamos permanentemente antes de tomar una decisión de implementación, pero que no siempre buscar su equilibrio es lo correcto para salir a producción.

Seguir probando versus implementar a tiempo es una discusión frecuente en las organizaciones que desarrollan software y el tipo de industria determinará cuánto riesgo puedo tomar de cada lado de la balanza. 

Por ejemplo en industrias muy competitivas, el time to market y la oportunidad de implementación son ventajas competitivas que pesan muy fuerte y que en ocasiones pueden definir al ganador.

En ese tipo de industrias es muy frecuente que la balanza se incline del lado de la oportunidad de implementación. Por lo tanto la decisión de liberar el software deberá tomarse aún con el riesgo de no seguir probando. Es muy probable que cause más dolor para el negocio no salir a tiempo que encontrar un error.

El timing adecuado para liberar un release puede ser estratégico en ciertos contextos y es muy probable que compita contra la necesidad de seguir probando y encontrando defectos. Aún así tenemos la responsabilidad de tomar una decisión a tiempo y asumir el riesgo.

Por otra parte es probable que en industrias como la de la salud, la aeronáutica o la espacial, si bien existe un entorno de competencia, el dilema prácticamente no exista ya que una falla puede ser el fin del negocio. Esa situación resuelve fácilmente el dilema e inclina siempre la balanza para un mismo lado. Las decisiones son muy simples: implementar sólo cuando nos encontramos frente a un alto grado de certeza de que no habrá errores.

Ahora bien, en las industrias donde se presenta este dilema a diario, es sumamente importante tener la sensibilidad y la información necesaria para determinar cuál es el punto justo en el cual debemos tomar la decisión de liberar un release.

Supongamos que podemos representar la relación que existe entre el tiempo y el riesgo de no implementar a tiempo. En una industria muy competitiva probablemente esa curva tenga la siguiente forma:

Por otra parte si graficamos la relación entre el tiempo de prueba y el riesgo de encontrar errores tendríamos una curva probablemente de esta otra forma:

Ambas curvas muestran que a medida que pasa el tiempo el riesgo de encontrar un error disminuye, ya que en general la mayor cantidad de errores son detectado en los primeros ciclos de prueba pero a su vez el riesgo de no implementar aumenta. (es probable que nuestro competidor por ej. haya lanzado la nueva versión o el nuevo feature antes que nosotros).

Si miramos juntas ambas curvas se puede observar que se cortan en un punto.

La pregunta es:

¿podemos inferir que el punto de corte representa el mejor momento para liberar software?

Si la respuesta es afirmativa, entonces podríamos decir que cualquier decisión que se tome a la izquierda de ese punto tendrá asociado un alto riesgo de encontrar errores luego de la implementación y con un costo mayor al de no implementar a tiempo.

Por el contrario, cualquier decisión que se tome hacia la derecha de ese punto tendrá asociado un alto riesgo de fracaso frente a la competencia aún cuando no tengamos errores.

Es interesante poder hacer este ejercicio a diario y pararnos frente a este dilema para preguntarnos si al seguir probando no nos estamos perdiendo la oportunidad de salir al mercado a tiempo y si esa situación es la correcta para nuestro negocio.

Técnicas Agiles tanto de gestión de proyectos (Scrum) como de desarrollo/release management tales como Continuos integration, test unit, TDD, risk testing, testing automático, son excelentes herramientas y prácticas cuyo objetivo es contribuir a tener desarrollos siempre listos para ser implementados. Tienden a reducir el gap entre implementar a tiempo vs seguir probando. Colaboran también a mejorar la toma de decisiones cuando se evalúa el grado de riesgo que estamos asumiendo al momento de liberar un nuevo release. 

Hace poco en una conferencia escuché al CIO de una compañía decir lo siguiente:

"cualquier macana se perdona si lo que estamos implementando es lo mejor que hay en el mercado".

creo que eso resume perfectamente este dilema.