Development GP: la carrera del desarrollo.

Hoy en día, en este mundo de la mal llamada consultoría, en el que vivimos la mayoría de los expertos en TI, existe una clásica obsesión entre los ‘clientes’, jefes de proyecto, gerentes y, a veces, incluso entre los Scrum Masters.

Se da sobre todo en los equipos que utilizan metodologías de trabajo más modernas, alejados del clásico Waterfall. Esa obsesión es la velocidad, entendiendo velocidad como la cantidad de funcionalidades de negocio desarrolladas (que no necesariamente testeadas) en un periodo de tiempo.

Si hablamos de velocidad seguro que se nos vienen, por lo menos, un par de conceptos a la cabeza y uno de ellos serán las carreras, por ejemplo, de Moto GP. En este tipo de competiciones la velocidad y el tiempo, al igual que en el software, son algunos de los factores cruciales.

A la hora de competir en una carrera existen muchas posibilidades y estrategias. Un piloto novel verá la carrera como algo muy simple: ‘Necesito llevar siempre la máxima velocidad posible para acabar cada vuelta cuanto antes’ de forma similar a como actúan algunos gestores con una visión más simplista del proceso de construcción de software.

Nuestro piloto novel empezará la carrera y después de varias vueltas, gracias a su pericia, rápidamente se situará en cabeza. Pero por desgracia para él, no acabará la carrera primero. Porque se va a producir una de las siguientes tres situaciones:

• Yendo primero, en una curva entrará demasiado pasado y se saldrá de la trazada, perdiendo varias posiciones. Aunque conseguirá acabar en los puntos.
• Después de unas cuantas vueltas, entrará en una curva muy pasado y se caerá, la moto sufrirá daños y nuestro piloto tendrá que abandonar la carrera.
• Ya casi llegando al final, aguantando al segundo, hará una curva demasiado rápido, se saldrá del circuito y tendrá un accidente que le provocará una lesión. Como consecuencia de esto, se perderá las 3 siguientes carreras.

¿Qué es lo que provoca que nuestro piloto no pueda acabar la carrera en ninguna de las 3 situaciones? Los que estéis familiarizados con las carreras de Moto GP ya tendréis algunas teorías. En este caso estoy hablando de los de los neumáticos, el desgaste de los neumáticos.

Cuando los neumáticos están desgastados esto provoca que el agarre disminuya, lo que no nos permite circular tan rápido, además de aumentar el riesgo de caída. El desgaste de los neumáticos es un factor que los pilotos tienen en cuenta durante toda la carrera.

Mucha de la estrategia existente gira en torno a ellos, desde ya antes de la carrera a la hora de escoger la dureza hasta durante la carrera a la hora del tipo de pilotaje que se realiza.

Un piloto no puede salir a correr con una estrategia tan simplista como ‘llevar la máxima velocidad posible’, sino que tiene que prestar atención a muchos otros factores.

En este caso, es cierto que su objetivo principal es la máxima velocidad posible (o acabar en el menor tiempo posible), pero esto siempre se debe producir dentro de un marco de seguridad.

De nada sirve estar haciendo unos tiempos geniales e ir primero si en las últimas vueltas te sales y no puedes acabar la carrera**.**

De forma similar ocurre en el desarrollo del software. Nuestro objetivo puede ser (que tampoco es recomendable) la mayor velocidad posible, pero siempre y cuando esto se dé dentro de un marco de seguridad. Y podéis pensar ‘bueno, yo no voy encima de una moto, no me voy a estrellar’.

Traslademos las 3 anteriores situaciones a sus análogos en desarrollo del software. Tu equipo de desarrollo ha terminado una funcionalidad en un tiempo récord y están listos para desplegarlo en producción:

• Resulta que tu aplicación tiene un bug, el equipo lo detecta al poco de desplegar y lo resuelve. Como era un bug sencillo los clientes que lo han visto no le han dado mayor importancia.
• Tu aplicación tiene un bug importante, el equipo lo detecta al poco de desplegar. Como su resolución requiere mucho tiempo se tiene que dar marcha atrás el despliegue y no se podrá poner la nueva funcionalidad en producción hasta dentro de varios días. El valor que se iba a proporcionar al cliente se retrasa. Incluso podría ser una promoción que ya no se podrá aplicar.
• Tu aplicación tiene un bug crítico. Ha estado en producción solo una hora y ya se ha retirado volviendo a la versión anterior. Pero el daño que ha causado a tus clientes es tan grave que muchos deciden darse de baja de tu servicio. Si resulta que además es una aplicación/servicio muy ampliamente utilizado, el bug será publicado en medios de comunicación y el daño a la reputación de tu empresa puede provocar desde grandes pérdidas, hasta hacerte quebrar.

Ahora que ya tenemos claro los problemas que podemos tener, vamos a definir en que se traduce ese ‘marco de seguridad’ que nos va a permitir ‘terminar la carrera sin percances’.

Dentro del mundo del software existen unos procedimientos, recomendaciones, buenas prácticas… que nos permiten ‘hacer la carrera dentro del trazado’ pudiendo así centrarnos en otros aspectos como podría ser la velocidad. Prestar atención a los siguientes puntos nos hará llegar a la meta de la mejor forma posible:

Metodologías ágiles

Las metodologías ágiles nos permiten reaccionar rápido ante los cambios y adaptar nuestra estrategia a la nueva situación. Como piloto puedes pensar en hacer una conducción conservadora manteniendo tu tercer puesto para atacar al primero en las vueltas finales, pero si resulta que el segundo está yendo muy lento y el primero se os está escapando, deberás ajustar tu estrategia y forzar para adelantar al segundo.

Estos factores cambiantes pueden ser completamente ajenos a nosotros, por eso es imprescindible poder adaptarnos a los cambios.

Puedes haber diseñado una estrategia de carrera genial, haber escogido los neumáticos muy bien e ir rodando primero con una gran ventaja y de repente empieza a llover y resulta que tú llevas los neumáticos blandos (los neumáticos blandos se comportan mejor en seco dando un mayor agarre; en lluvia no tienen tanto agarre impidiéndonos hacer una conducción tan rápida como con unos duros).

Un cambio completamente ajeno a ti que invalida tu estrategia actual. Tendrás que cambiar tu estrategia, porque a lo mejor ser primero ya no es siquiera una opción viable, a lo mejor ahora simplemente optas a los puntos, ya ni siquiera al podio.

Pruebas automáticas end-to-end

Un piloto jamás se plantearía subirse el día de la carrera a una moto que no ha probado previamente en los entrenamientos. El día más importante de la semana, el que cuenta para el campeonato.

¿Y tú te planteas subir a producción sin haber probado? Sé lo que estarán pensando muchos ‘La aplicación tiene sus tests unitarios y de integración, así que está todo probado’. Por desgracia eso no es suficiente para garantizar tu seguridad en carrera.

¿Crees que un piloto saldría a carrera con una moto en la que motor, frenos, aerodinámica y neumáticos se han probado por separado? Puedes tener unos frenos y un motor muy bueno, pero llegado el momento de la carrera resulta que esos frenos, aún siendo muy buenos, no están a la altura del motor, es decir, no tiene suficiente capacidad de frenado para las velocidades que alcanzaremos (también relacionadas con la aerodinámica).

Cuando salgas a carrera, en una de las primeras vueltas te saldrás en una curva, debido a que tus frenos no fueron capaces de pasar de 300 km/h a 120 km/h en 30 metros. Tus frenos que eran tan buenos.

De la misma forma es importante que tus pruebas sean end-to-end, es decir, que pruebes el conjunto de tu aplicación junto con sus dependencias. Un requisito puede ser responder a una petición de cliente en 200 ms, el equipo ha desarrollado y probado el código y tarda solo 100ms.

Todo perfecto, hasta que llegas a producción y la llamada que dicha funcionalidad hace a servicios de un tercero tarda 10s en responder.

Pruebas de carga/estrés

Dentro del mundo de las pruebas, las que casi siempre se llevan la fama son las pruebas funcionales. Probar que todo funciona correctamente, que todo se visualiza bien, probar todos los casos de uso.

Pero rara vez nos acordamos de las pruebas de carga y las pruebas de estrés. En los modelos waterfall sí que eran más habituales estas pruebas. Después de un año de desarrollo, antes de salir a producción, probabas que la aplicación aguantaba tu carga esperada de usuarios y un poquito más, ya sabes, por si acaso.

El caso es que con metodologías ágiles y con Continuous Delivery la nueva funcionalidad ya no es una aplicación entera, sino una nueva pequeña funcionalidad. Pero eso no quiere decir que no requiera pruebas de carga y de estrés.

Para mi la visión es muy sencilla, si despliegas una nueva funcionalidad pensada para ser consumida por un total de 1000 usuarios y luego resulta que solo 3 la pueden utilizar porque no aguanta la carga, a efectos prácticos es como si no hubieras desarrollado la funcionalidad porque la mayoría no podrán usarla.

Esa funcionalidad incluso puede ser utilizada por otras y si no incluiste circuit breaking y gestión del fallback puede provocar que otras funcionalidades más cruciales dejen de funcionar.

La situación puede incluso llegar a ser peor, ya que debido a que no es capaz de soportar la carga puede llegar a tirar la aplicación completa.

Volviendo al mundo de Moto GP esto se hace más obvio aún. ¿Crees que un piloto correrá en una moto que no han probado a 300 km/h?, ¿que no ha comprobado si aguanta a 200 km/h durante la casi una hora que dura una carrera?

Las consecuencias son las mismas, sales a pista, y en las últimas vueltas apretando a fondo, te pones a 313 km/h en la recta y… se rompe el motor. Todo los entrenamientos, clasificación y carrera tirada por la borda.

DevOps

Cuando el domingo a las 14:00 h pones la carrera, lo que ves son un montón de tíos subidos en sus motos, pisándole a fondo y tumbando que no veas en las curvas.

Ellos son los protagonistas, son el centro de atención, sus nombres los que se escuchan en la retransmisión. Y, de vez en cuando, ves un plano del box ¿y qué ves en el box?

En el box hay otro montón de tíos, pero estos no son protagonistas, no se conoce el nombre de casi ninguno. Ellos son los mecánicos, los ingenieros, el jefe de equipo… Por cada uno de los que hay en pista hay un montón más en el box, pero todos están ahí para lo mismo: para ganar la carrera.

Todos ellos, independientemente de su área de conocimiento o habilidad: sean ingenieros de aerodinámica, especializados en motores, mecánicos, el piloto… tienen un único objetivo común: ganar la carrera. Cada uno tendrá su tarea individual, pero todas van encaminadas al mismo objetivo.

Esto mismo es lo que debe ocurrir con Desarrollo y Operaciones (y los departamentos que sea: Calidad, Análisis...) en una empresa.

No deben estar aislados entre sí, agrupados por capacidades técnicas, mirando cada uno por los objetivos de su departamento y recibiendo peticiones vía documento, o correo, o ticket. Deben integrarse, trabajar conjuntamente, independientemente de que disciplina vengan, su objetivo debe ser el mismo y todos deben formar parte del mismo equipo.

Arquitectura

¿Te imaginas a un piloto saliendo a correr el Gran Premio de Alemania con una scooter? No ¿verdad? Una scooter no puede competir con el resto de motos de la parrilla.

Hay motos de carrera de competición, hay motos para circular por el campo y hay motos para circular por ciudad. Y hay algunas que sirven para circular por varios sitios. Pero cada una ha sido diseñada y optimizada para una finalidad concreta y aunque pueda servir para otra, ahí no va a ser donde va a brillar.

Para los no conocedores del mundo de las dos ruedas: un Ferrari es un gran vehículo, una máquina increíble, pero ¿a que no sería tu opción si tuvieses que hacer una ruta por el monte? Probablemente preferirías un todoterreno. El todoterreno también puede circular por un circuito de carreras, pero no ha sido diseñado para ello, puede hacerlo, pero ahí no será donde le saques partido.

De forma similar existe una arquitectura software pensada para cada situación. Hay algunas más específicas y otras de ámbito más general. Pero es importante que conozcas cuál es el entorno en el que te vas a mover, ya sea el monte o un circuito, para escoger la solución adecuada para moverte.

¿Una moto de carreras con ruedas de scooter? ¿Una scooter con un motor de 1000cc? Suena a accidente seguro. Todas las piezas que componen tu solución deben encajar y funcionar en armonía.

Tu arquitectura corporativa puede no servir para tu siguiente proyecto**.** Puedes haberte pasado toda la vida con bases de datos relacionales, pero a lo mejor el siguiente proyecto, por necesidades de rendimiento, necesita una NoSQL. Quizá siempre hayas circulado por ciudad, pero ahora te toca salir a carretera.

Mejora contínua

A lo largo del mundial de Moto GP, que suele tener una duración algo inferior a un año y coincidir con el año natural, los pilotos suelen cambiar de modelo de moto. No todos, no siempre y los cambios en el modelo son ínfimos, pero a veces se producen.

Esto es porque durante el propio mundial el equipo de ingenieros y mecánicos siguen trabajando buscando mejorar la moto en todas sus facetas posibles. El ritmo de competición es tan vertiginoso que si tienes una mejora, por pequeña que sea, no debes esperar al siguiente mundial para ponerla en tu moto.

Una vez que esta haya sido evaluada y probada entrará para la siguiente carrera. Porque esa mejora, por pequeña que sea, te puede hacer ganar la siguiente carrera.

Los ritmos del mercado no son tan vertiginosos (aunque el piloto ‘sale a producción cada semana’ y tú estás de forma contínua en producción), el ritmo de desarrollo del software también es más lento, pero eso no quiere decir que los cambios no se produzcan rápido.

El principal problema con el que nos encontramos aquí es que la mayoría de compañías ven los procesos de diseño y desarrollo de software como estáticos. Escogen una arquitectura con una serie de herramientas/librerías/frameworks y esa es la verdad absoluta para toda la vida de la aplicación.

Parece que hubieran encontrado la arquitectura perfecta. ¿Cuántas empresas no diseñan una arquitectura corporativa y la utilizan para todos sus proyectos durante años? A veces, incluso, llegando a la década.

Puede que ese tipo de prácticas sirvieran hace 30 años, cuando la industria del software era otra cosa, pero hoy en día eso no es una opción.

Hoy en día la tecnología cambia a una velocidad vertiginosa y una solución puede haber recorrido todo su ciclo de vida (desde la aceptación, llegando al éxito y la posterior extinción) en menos de dos años.

Pensar que una arquitectura corporativa puede durar 5 años sin actualizarse es cuanto menos iluso.

Por eso es importante no cerrarse las puertas a los cambios, a los nuevos frameworks, a los nuevos paradigmas arquitectónicos… en definitiva, a la innovación.

Coge cualquier proyecto, cualquier aplicación y siempre podrás encontrar algo que mejorar. A veces cuando la aplicación ya tiene una cierta vida: la arquitectura ha sido diseñada, se ha añadido una funcionalidad considerable, lleva ya un tiempo en producción... nos centramos en únicamente desarrollar nueva funcionalidad o resolver bugs y perdemos el foco.

La tecnología está viva, en cambio constante, progresando, renovándose, evolucionando y es necesario que asimilemos esa naturaleza cambiante y la traslademos al software que producimos.

No existe una versión definitiva perfecta de una aplicación, siempre hay algo que mejorar y ahí tenemos que estar, para que cada día que pase, nuestro software sea mejor.

Conclusión

En mi paso por esta industria he visto todo tipo de situaciones saliéndonos del marco de seguridad: desde salir a producción sin pruebas de estrés, no abordar deuda técnica dejando que esta se incremente sprint tras sprint (con el consiguiente aumento de costes operativos) hasta salir a producción sin haber realizado una simple prueba manual y SÍ, esto pasa, sigue pasando, todavía hay gente en esta industria que considera eso una opción.

Saliéndonos ya del mundo de Moto GP, y volviendo a nuestra realidad del día a día: coger el coche o la moto para ir a trabajar; hay una analogía, que es mi favorita que es la del cinturón de seguridad.

Eso me hizo pensar que en ese mundo del día a día también existen unas normas de seguridad. Normas definidas por la DGT, algunas obligatorias, que nos dicen a qué velocidad máxima debemos circular, que debemos llevar el cinturón...

Otras son recomendaciones, que si bien no son obligatorias nunca están de más, como por ejemplo tener un vehículo con ABS. Al final son unas reglas y recomendaciones puestas por los expertos, la DGT, para que la mayoría de la población pueda conducir en un marco de seguridad.

De la misma forma, en la industria del software existen recomendaciones, buenas prácticas, estándares… que han sido definidos por los mayores expertos. Organizaciones que han pasado por esa experiencia y han determinado la solución correcta y cuales son los riesgos potenciales.

Esas prácticas y estándares son refrendadas por otras compañías que las llevan a cabo y ven cómo las situaciones son solventadas con éxito. Todo esto se convierte en una suerte de experiencia del sector, un ‘know how’ que retroalimenta a quien se expone de nuevo a dichas situaciones.

Y ahora es tu turno. Esas buenas prácticas, esas recomendaciones, están ahí. Han sido probadas y confirmadas como exitosas por el conjunto de la industria. La carrera pronto va a comenzar, todos los pilotos están en sus puestos, ¿vas a salir a correr en una scooter?