¿Nadas rápido o nadas despacio?

Como nadar nos ayuda a entender mejor el desarrollo de Software

Desarrollar rápido no es escribir líneas de código deprisa.

El otro día, José, nos compartía al equipo por Slack, que a él le gustaba comparar esa frase, con el estilo de natación que utilizan alguno en la piscina. Por un lado, están los nadadores amateurs como yo, que creemos que vamos a toda velocidad, por levantar mucha agua con los brazos y mover de forma desproporcionada el cuerpo. Y por otro, la gente que de verdad sabe nadar, que con cuatro brazadas gráciles, avanza a toda pastilla por la piscina, sin casi levantar una gota de agua. En el vídeo se ve con mejor detalle, como una buena técnica, te ayuda a poder nadar más rápido por encima de la fuerza bruta. Pero la pregunta es: ¿qué es nadar rápido o despacio en el desarrollo de software?

Nado rápido

Un programador que desarrolla rápido, programa menos horas a la semana. Invierte tiempo entendiendo que se quiere conseguir con la nueva funcionalidad.

Coge un papel y dibuja las relaciones entre las distintas partes de código que tiene que programar. Al terminar, “molesta” durante una hora a otro compañero, debatiendo la solución que ha ideado, para identificar problemas y encontrar conflictos con otras funcionalidades de la solución.

Con eso, hace un par de pruebas que sabe que va a tener que reescribir para validar que la solución que ha planteado tiene sentido. No es un MVP, es una “primera versión con muchas pinzas”. Como no, las dudas no hacen más que crecer. Para resolverlas es necesario otra reunión de refinamiento con alguien de negocio para resolver cuestiones que técnicamente dan igual, pero que podrían dejar el producto inservible en unos meses.

Una vez solucionadas estas preguntas toca ponerse manos a la obra. Y lo primero no es escribir una función que resuelva el core del problema, no. Lo primero que hace es escribir un test, que verifique que sólo llegará a producción código nuevo que se comporte como el desarrollador pretende y que además cumpla con todos los casos de uso previos.

---

Cuando me contaron bien esta parte del proceso me pareció que resolvía de una forma muy elegante algo que yo nunca he conseguido resolver en mis proyectos que es encontrarte en un punto de no retorno con todo roto. Al ir poniendo pequeños trozos de código que verificasen tu propio código te aseguras de que en caso de meter algún cambio que modifique algún comportamiento de tu proyecto, haya otra parte de código que se asegure de avisarte de que no puedes seguir cambiando cosas por ahí.

---

Ese primer test, va a fallar cuando hagas el commit a producción. Es decir, hasta este punto, ningún usuario ha recibido la funcionalidad para la que el desarrollador lleva trabajando toda la semana. A partir de aquí es cuando la cosa se pone divertida. Se programa la función, el test pasa y el código se despliega automáticamente por distintas fases hasta que llega al usuario. Idealmente, hay suficiente cobertura de tests y unos pipelines, montados, para que todo esto pase de forma automática. Pero no necesariamente, tener un Jenkins que empuja código a distintos entornos hace que vayas a desarrollar más rápido.

Y entonces, ¿qué es nadar despacio?

Si oyes alguna de estas frases en tu equipo al mes, puede que tu equipo nade despacio.

— Esta semana seguiré intentando mergear las ramas

— Me ha echado para atrás el ticket QA, luego lo miro

— Se ha vuelto a caer el entorno de desarrollo, hasta mañana no puedo avanzar

— Desarrollo me ha vuelto a decir que no

— He terminado la funcionalidad, podemos empezar con el pase a producción y estará disponible en la release del próximo mes

Antes de que estos comentarios puedan sentar mal, estas frases no siempre dependen del equipo directamente. Hay un contexto que te obliga a ir despacio. A mí personalmente no me gustaría que la funcionalidad de cobros de Bizum, llegase a producción sin que 100 personas de QA se asegurasen a la perfección de que no hay forma de que un tercero saque dinero de mi cuenta. Salud, banca, ejercito, … Son sectores dónde la regulación o la importancia de los datos que se gestionan hacen que el desarrollo de software vaya más despacio.

Por otro lado, hay equipos que han visto como sus formas de trabajo han cambiado de forma radical en los últimos 10 años sin un acompañamiento adecuado. Scrum, cloud, CI/CD, IA, blockchain, … ¿Cómo podemos esperar que nadie sepa qué tiene que hacer, si la información ha ido llegando de forma desordenada? ¿Y lo del metaverso, eso sigue en pie?

Por eso es importante entender cuáles son esos principios que nos ayudan a ir despacio o rápido y aprender a implementarlos con éxito dentro de la empresa.

En resumen, desarrollar rápido implica una serie de dinámicas, que no son obvias a nivel de negocio y que es bueno conocer:

-       La primera es que el desarrollador no tiene que estar todo el día programando. Para eso puedes coger a ChatGPT y seguro que es capaz de programar más líneas de código por hora que cualquier desarrollador. La productividad de un desarrollador tiene que ir en línea con programar código que se pueda mantener y evolucionar, mientras vamos introduciendo nuevas funcionalidades. Muchas veces, es la primera parte la que queda olvidada.

-       El segundo punto es que no puede haber alguien responsable de QA. La calidad funcional del código tiene que depender de cada individuo. Si se ha desarrollado “mal” o no se comporta según lo pensado, no pasa nada. Somos mayores para identificar el problema arreglarlo y seguir con el día a día. El concepto de una persona cuyo único objetivo es identificar problemas en el código y que el desarrollador dependa de esa validación de un tercero para continuar su trabajo se ha quedado en mi opinión muy anticuado.

-       Por último, los desarrolladores son responsables de mucho más que la última funcionalidad. Cuando alguien del equipo de desarrollo me transmite “No estamos preparados para esta funcionalidad ahora” me transmite una tranquilidad absoluta. La misma funcionalidad en dos momentos distintos puede tener tiempos de desarrollo de una semana o un trimestre. Hacer caso a los desarrolladores del estado de madurez para asumir ciertos proyectos es fundamental.

El desarrollo de software tiene unas bondades intrínsecas de escalabilidad que lo hacen muy atractivo de cara a que las organizaciones lo integren dentro de su conjunto de herramientas. Para poder conseguir los retornos esperados, es necesario crear un espacio dónde haya una cultura de desarrollo de software fomente estas buenas prácticas.

Al final de todo, no por nadar más fuerte, vas a llegar antes.