Acelerando la Innovación: Automatizando el Desarrollo de Software para Obtener Ventaja Competitiva

El desarrollo de software tradicional es lento. Es hora de repensarlo.

Hace casi tres años, Satya Nadella de Microsoft acuñó famosamente que «cada negocio será un negocio de software». Hoy, el mercado global de software de 500 mil millones de dólares está en camino de duplicarse a 1 billón para 2030.

J.P. Morgan registra tener 40,000 ingenieros de software (más que Alphabet) en su presentación más reciente. Cada gran empresa compite por contratar ingenieros para superar a su competencia en desarrollo. El gran problema es que el desarrollo de software tradicional es lento, fragmentado y derrochador.

Por ejemplo, cada semana el ingeniero de software promedio pasa 4 horas esperando a que se completen las pruebas, 3.5 horas esperando builds, y 3 horas en gestión de entornos —más de una cuarta parte de su semana laboral sin crear nada de valor. Considerando que los ingenieros suelen ser las personas mejor pagadas en las organizaciones, es claramente un gran problema. Sin embargo, las cosas están cambiando.

Una de las plataformas de desarrollo líderes, CircleCI, apostó que la IA y la automatización serían la clave para acelerar la innovación en software y liberar a los ingenieros para hacer trabajo importante. En el último año, la empresa introdujo una serie de mejoras de automatización y aprendizaje automático que redujeron el tiempo que los ingenieros pasan esperando en un 50%. Es una de las muchas razones por las que más de 300,000 desarrolladores, incluidos los de Facebook, Spotify, GoPro, InstaCart y muchos otros, han recurrido a CircleCI para moverse más rápido.

Lidera la empresa Jim Rose —un fundador en seis ocasiones con inversiones previas de Google Ventures, Foundation Capital y Marc Andreessen. Desde que se unió a CircleCI hace poco más de cuatro años, Rose ha aumentado los ingresos en más del 450% y ha convertido a la empresa en una entidad verdaderamente emocionante.

¿Interesado en aprender más sobre la automatización del desarrollo de software y la aceleración de la innovación? Information Age habló con Rose sobre el tema.

¿Cuál es el estado actual del mercado de software?

En este momento, todavía hay muchas empresas e individuos que realizan diferentes procesos manualmente. Cuando piensas en el proceso de transformación digital, realmente se trata de fomentar un equipo de desarrollo de software.

Primero, se intenta sacar el software de los centros de datos on-premise y llevarlo a entornos cloud-native, donde se puede acceder a computación de forma instantánea.

Segundo, el software, tradicionalmente o en muchos casos, se ha visto como una guía o un complemento del negocio principal. Ahora todo tipo de negocios —desde bancos hasta fabricantes de automóviles y minoristas— se dan cuenta de que el software es central para lo que hacen. Y necesitan descubrir qué poseen y tienen que consolidar sus activos e integrarlos como estándar.

Una vez que las empresas tienen este acceso instantáneo a computación y tienen estructuras donde los desarrolladores pueden trabajar, lo que está en medio hoy suele ser una mezcla de diferentes plataformas y procesos.

En la mayoría de los casos tienes procesos de lanzamiento de software en cascada muy largos que tienen muchos pasos manuales y luego muchos scripts manuales. En algunos casos, para tiendas más avanzadas, podrían tener la primera generación de soluciones de automatización, pero a medida que los equipos aceleran, esas empiezan a romperse.

Y eso es en lo que estamos entrando y ayudando a las empresas a navegar. A medida que sus equipos de software aceleran, construyen más software y al intentar hacerlo más rápido; para ser tanto responsivos a oportunidades en el mercado como a posibles cambios negativos. Las empresas simplemente necesitan repensar completamente cómo se juntan todas esas piezas.

¿Es esta velocidad a la que te refieres el principal obstáculo en el desarrollo de software?

Las empresas y los equipos de desarrollo intentan acelerar porque el mercado se está acelerando. Están intentando averiguar cómo pueden trabajar rápido para poder abordar oportunidades.

La única forma de llegar allí es automatizar realmente todos los pasos que no necesariamente requieren intervención humana, porque en lugar de hacerlo en el transcurso de minutos, horas y días, puedes hacerlo en segundos.

A medida que los equipos aceleran, y el software es tu principal escaparate hacia tu cliente, tienes que asegurarte de que los niveles de calidad sean altos; tienes que asegurarte de que no falle o que no tengas vulnerabilidades de seguridad, por ejemplo.

Así que, cuando piensas en ágil, se trata de intentar volverse más ágil, tanto desde una perspectiva de calidad como de velocidad.

En EE. UU. todo se trata de velocidad, pero al ir más rápido, integrar trozos más pequeños y poder lanzar software de forma más consistente, tu software inherentemente mejora. Todos esos miedos sobre tener que desplegar desaparecen cuando lo haces cinco, ocho, 15 veces a la semana, y en algunos casos tenemos clientes que lo hacen 100 veces al día.

El despliegue se convierte en un no-problema.

En el lado de la calidad, uno de los grandes problemas para el desarrollo de software en el pasado es que si solo lanzas una vez por trimestre, tienes un momento muy difícil asegurando que todos los cambios que introduces en tu aplicación realmente funcionen juntos. A menudo ves empresas hacer un lanzamiento big bang y luego, después, pasan los siguientes 60, 90 días intentando arreglar todas las cosas que regresaron y se rompieron. En este método, tu ciclo de software se ralentiza, pero también la calidad de la aplicación en sí sufre.

Desde una perspectiva ágil, eso es lo que la gente está intentando abordar.

¿Cómo puede una organización cambiar para acomodar, apoyar y fomentar equipos de desarrollo de software?

Hay varias formas diferentes.

Una es que los desarrolladores son difíciles de contratar, así que quieres asegurarte de que todo el tiempo dedicado desde una perspectiva de desarrollo se dedique a construir tu software especial, sea lo que sea; si eres un banco, construyendo una gran aplicación bancaria, si eres una app de e-commerce, construyendo una app de e-commerce realmente buena. Creo que una de las grandes áreas en las que la gente ha subinvertido es que los desarrolladores de software históricamente construían cosas. Eso es lo que hacen, construyen software. Así que el ciclo de desarrollo ha sido subinvertido desde una perspectiva de aplicaciones de terceros.

Simplemente hay cosas como, por ejemplo, automatización de pruebas e infraestructura de entrega continua que los equipos no deberían tener que construir por su cuenta. Estás mucho mejor adquiriéndolo de alguien más que se especialice en ese área para que puedas centrarte en lo que eres bueno. Sería como decirle a alguien que necesita construir una cafetera y darle un montón de tubos de cobre, estaño y válvulas. Nunca harías eso. Pero históricamente, el desarrollo se ha tratado de esa manera. Así que definitivamente poner las herramientas y plataformas correctas en su lugar es realmente crítico, todo el camino arriba y abajo de la pila, desde el centro de datos hasta las herramientas de planificación.

Creo que la segunda parte es que en un modelo de cascada tradicional, el desarrollo de software suele jugar el papel de receptor, por lo que la aplicación se define mucho antes en el proceso y luego, cuando el equipo de desarrollo la recibe, se han tomado una serie de decisiones que pueden o no funcionar realmente y pueden o no ser factibles o fáciles de hacer.

Existe esta noción de «shift left», que intenta empujar el desarrollo cada vez más arriba en el ciclo de planificación para que las preocupaciones o necesidades del equipo de desarrollo se consideren tanto en la construcción de la aplicación como en su entrega. Y luego, cuando lo piensas desde una perspectiva operativa, significa que realmente tienes que pensar en cómo se opera una aplicación mucho antes en el ciclo de vida también. Por ejemplo, si intentas construir apps cloud-native, tienes que arquitectarlas de una manera muy particular, lo que significa que necesitas tomar esa decisión y ser parte de ese proceso mucho antes.

Cuando los equipos adoptan procesos más software-first, ágiles, terminas con una triangulación de preocupaciones. Tienes a la gente y a los dueños del negocio y gerentes de producto que poseen el porqué estás construyendo algo. Tienes a los arquitectos técnicos y desarrolladores de software hablando realmente sobre cómo lo construyes. Y luego tienes a los operadores, los responsables de ejecutarlo realmente, averiguando qué se ejecuta al final de todo ese proceso. Así que todos necesitan estar involucrados. Y eso puede ser una transición dura para algunas empresas.

¿Cómo pueden la IA y la automatización impulsar y mejorar la innovación en software?

Con la automatización puedes automatizar tareas que son tanto predeterminadas como de autoaprendizaje. Un ejemplo podría ser si cada vez que intentas lanzar un software tienes que hacer una prueba de terceros contra algún otro sistema de pagos de terceros. En el pasado con esas tareas, tenías que contratar un equipo de QA que esencialmente intentaría procesar transacciones y hacerlo todo manualmente, lo cual es increíblemente lento. También es increíblemente propenso a errores y complicaciones.

Estos son ejemplos perfectos de tareas que deberían estar completamente automatizadas en tu suite de pruebas —todas esas cosas que sabes que vas a hacer una y otra vez, deberías automatizar esas tareas para hacerlas deterministas y predecibles. Y finalmente rápidas.

Hay oportunidades para tomar esas tareas repetitivas que cualquier minuto que un desarrollador pase haciendo esas cosas una y otra vez es una pérdida de tiempo y, francamente, una pérdida de dinero.

Así que cuando miras la IA y el software que se está construyendo, en lugar de pensar en empujar software predictivo determinista, lo que estás haciendo es empujar un modelo. Y el modelo es un sandbox de nociones preconcebidas de cómo algo podría funcionar y luego, a medida que la gente lo recorre y se ejecutan las pruebas, el modelo cambia y evoluciona a medida que aprende más sobre cómo las cosas están funcionando o no. Eso ejerce una presión increíble sobre el sistema de pruebas.

Cuando piensas en algunos de los errores de la IA, cuando tienes situaciones donde hay sesgo inconsciente incorporado en la IA, donde la IA se descontrola y empieza a bloquear a personas de ciertas aplicaciones, o apaga cosas, esas son todas situaciones que desde una perspectiva de pruebas son desafiantes.

Se está volviendo cada vez más complicado, pero también mucho, mucho más rápido y responsivo. Así que solo vas a ver la inclusión de IA y aprendizaje automático en el desarrollo de software continuar aumentando. Pero, ahora necesitas tener todos los marcos necesarios en su lugar para poder probar todos esos cambios.