Te va a interesar!

6/recent/ticker-posts

Se viene el problema del crunching?

Hace unos meses veía en las noticias del mundo del desarrollo de videojuegos (da la casualidad que tengo como hobby crear fichines y me gusta mantenerme actualizado) una problemática que se destapó como una olla a presión: El crunch.

Esto que se conoce como "crunch" significa, simplificando un poco, la necesidad de trabajar muy por encima de las horas estipuladas para llegar a terminar actualizaciones que tienen que ser entregadas cada vez más rápido. Es algo que pasa especialmente con empresas AAA y recibieron muchas denuncias por parte de sus desarrolladores por tener jornadas de hasta 16 horas para llegar con la fecha de entrega de un parche por ejemplo.

Estos períodos de tiempo, que muchas veces son para un hotfix por errores que, a todo ésto, vinieron causa de tener que entregar las cosas más rápido de lo que se pudieron probar como dios manda, pueden ser una semana, varias semanas y en los peores casos meses.

DevOps: Amigo o enemigo?

Todo esto se ve potenciado por las prácticas de DevOps, donde se acelera todo el proceso con integración continua, delivery continuo y todo el tiempo se están entregando pequeñas actualizaciones al usuario final que, si hay algo que no le gusta, es esperar para que solucionen cualquier error, pequeño o grande por igual.
Ahora DevOps, bien implementado, te deja un pipeline y culturas de comunicación espectaculares que logran que de A a Z todo fluya con interacción humana mínima. Pero he aquí el problema amiguitos: Lo que DevOps se encarga de agilizar mediante automatizaciones, cambios en la cultura de trabajo y herramientas, es el trabajo que lleva horas humanas detrás. El desarrollo del software y los errores y sus correcciones son algo que necesita de la mano desarrolladora detrás. Todo esto me llevó a un perturbador interrogante...

Puede ocurrir el crunch fuera de la industria de los videojuegos?

A ver, primero y principal, no veo motivos para decir que el software no relacionado a los videojuegos está exento de ser una potencial víctima de estas prácticas. La cultura actual es la de entregar los updates, correcciones y mejoras con la mayor velocidad posible al usuario. Una diferencia quizás que sí puedo señalar, habiendo trabajado como Tester tanto en videojuegos como software no gamer, es que en el SDLC de juegos el Testing se suele tener en menor estima que en los segundos. 

Esto lleva a que más errores pasen a Producción y que existan mayores corridas para responder a los furiosos gamers que usan las aplicaciones. El resultado es que estás corriendo para apagar incendios todo el tiempo, perdiendo la confianza de los usuarios y al mismo tiempo agotando peligrosamente a tus desarrolladores. 

En empresas gigantes como Rockstar con el lanzamiento de su último juego Red Dead Redemption 2 tuvieron que salir al cruce de empleados denunciando unas políticas abusivas para llegar a entregar el producto que ellos querían en el tiempo que necesitaban. 

Existe una solución actualmente al Crunch?

Ni. Todo esto generó una charla muy interesante sobre la creación de gremios, sindicatos, que aboguen por la salud mental de los desarrolladores y se denuncien estas prácticas para que no ocurran. Pero no se qué tan efectivo puede ser eso en la práctica. Siempre va a estar el que necesite el trabajo más que el que denunció y esté dispuesto a estirar sus horas de trabajo en favor de la empresa para asegurarse su puesto. 

En la industria indie la cosa pasa por la presión que uno se pone personalmente, siendo más una decisión de frenar un poco y entregar los updates a ritmos sanos, pidiendo la comprensión de los usuarios. 
En el mundo que nos movemos nosotros en Testing de Software, no creo que sea un problema para nosotros testers. Los que sufren ésto son los desarrolladores más que nada. Si hay automatizaciones en su lugar, todo el trabajo humano puede ser validado por estos scripts en el pipeline, dando lugar al deploy en caso de tener todo en orden. 

Lo que me lleva a una conclusión, nuevamente, perturbadora: El cuello de botella empieza a ser el ser humano en el mundo del software. Pensemos sobre lo que les decía al principio. Jenkins, Automation, CI y CD...DevOps, todo eso lleva a automatizar trabajo humano durante todo el pipeline del software. Desde que se escribe el código y se manda a la herramienta de SCM de turno hasta que a uno como usuario le cae el update. 

Pero...qué pasa cuando toda esa rapidez tiene al usuario clamando por errores o cambios en la experiencia y se vuelve al papel en blanco y el desarrollador tiene que hacer algo al respecto? Ahí es donde se encuentra el problema en la actualidad y, déjenme decirles...creo que es una problemática muy interesante que se nos viene en el horizonte y va a demandar cambios radicales en cómo se desarrolla el software.  

Publicar un comentario

0 Comentarios