¿Calidad de software? ¿Agilidad? ¿O ambas?

Calidad v/s Agilidad

Como desarrolladores, ¿cuántas veces nos hemos visto en la situación donde se nos pide algo muy rápido, y debemos sacrificar calidad (orden y buena escritura) de lo que estamos programando? Según mi experiencia, muchas. Esto puede ser justificado en ocasiones, pero no siempre.

Decidir entre la agilidad y una buena calidad de código al programar en una startup es un desafío complejo. Las startups necesitan avanzar rápidamente, a diferencia de productos ya establecidos en el mercado. ¿Cuáles son las consecuencias de optar completamente por la agilidad y la rapidez? Aquí te las explico, si no eres programador, también te puede servir.

Para entender las consecuencias de dejar de lado la calidad, imaginemos un párrafo de texto. Este párrafo tiene reglas de sintaxis como comas, puntos y tildes. Sabemos cuándo usar mayúsculas, minúsculas, guiones, etc. Aquí un ejemplo:

“Nadie sabe su nombre, solo sabemos que era una niña que vivía cerca de un bosque un poco frío. Esto lo intuimos porque siempre se cubría con una caperuza, que es una especie de capa con gorro. Suponemos que esta niña era linda o así nos gusta imaginarla.”

Ahora, imaginemos que está escrito así:

¿Qué pasa con este texto?

• Es difícil de leer.

• Cuesta entender de que se trata el texto.

• Si te digo que hay una falta ortografía, ¿la puedes encontrar fácilmente?

• ¿Cuánto te demorarías en modificar algo de la historia?

• Si le pides a un amigo que te ayude a continuar la historia, ¿qué tan fácil será para él seguirla?

Lo mismo ocurre con el código: si no tenemos un estándar o un set de reglas que nos ayude a escribir a todos de una manera unificada, desarrollar se vuelve más y más complicado en la medida en que pasa el tiempo y esto interfiere con nuestra capacidad de ser ágiles y rápidos.

https://stackoverflow.blog/2021/10/18/code-quality-a-concern-for-businesses-bottom-lines-and-empathetic-programmers/

Proceso de integración de estándares en Neat

Yo entré a Neat en enero de este año (2024). La primera semana fue muy tranquila, así que aproveché para revisar los repositorios (lugares donde almacenamos el código) y tratar de entender la base del producto. Me resultó un poco complicado comprender cómo estaban hechas algunas cosas, por lo que comencé a comunicarme con Javier (CTO) para aclarar ciertos puntos y le mencioné estos problemas. Fue entonces cuando nos dimos cuenta de que necesitábamos establecer ciertos estándares en Neat y nos propusimos implementarlos. Sin embargo, esto nos llevó a la siguiente pregunta: ¿qué nivel de sanidad necesitamos en el código? ¿Existe tal cosa como un código perfecto? No lo creo, ya que esto nos quitaría toda la agilidad. Para entender el porqué, imaginemos esto:

Caperucita está tejiendo una capa para su abuela. Ella quiere que cada punto sea perfecto, sin un solo hilo fuera de lugar. Así que, cada vez que encuentra un pequeño error, deshace todo y vuelve a empezar. Pasa horas y horas tratando de hacer la capa absolutamente perfecta.

Mientras tanto, su abuela está esperando con frío, necesitando urgentemente la capa para mantenerse caliente. Caperucita podría haber terminado una capa buena y funcional mucho antes si no se hubiera obsesionado con la perfección. La capa podría haber tenido un par de puntos fuera de lugar, pero aun así habría cumplido su propósito de mantener a su abuela abrigada.

Entonces, ¿Qué hicimos en Neat?

Investigamos nuestros proyectos y nos dimos cuenta de que teníamos 3 problemas core, hicimos una lista de las prácticas que consideramos importantes y que nos ayudarían a resolver esos problemas y evaluamos la complejidad de incorporarlas.

Para explicar cómo lo hicimos, debo contextualizarte un poco: en Neat usamos una variante de Shape Up, con ciclos de dos etapas: shaping (decidir qué vamos a construir) y building (poner manos a la obra).

De esta lista, elegimos las prácticas que podíamos manejar en este ciclo y las implementamos durante todo el building (entre 3 y 5 semanas, dependiendo del ciclo). Luego, en la etapa de shaping, hicimos retrospectivas para analizar el valor de lo que incorporamos, ver si nos sentíamos seguros para avanzar con nuevas prácticas o si necesitábamos seguir practicando y cómo hacerlo.

Imagen de una retro que tuvimos

Así, llevamos aproximadamente seis meses incorporando prácticas y mejorando cada ciclo. Erradicamos los problemas core que identificamos inicialmente y seguimos incorporando prácticas que nos ayuden a ser ágiles y buenos. Hemos adoptado varias prácticas que nos ayudan a mejorar día a día en todos nuestros proyectos.

A continuación, te comparto algunos comentarios de la última encuesta hecha a los desarrolladores de Neat:

• "La embarró los estándares de código y el lint que agregamos, me hace codear mucho más rápido”

• "Me ha gustado, veo que estamos todos más estructurados, se comparte el conocimiento y mejora la mantenibilidad en su completitud de Neat"

• "A modo personal, siento que existe una mejora continua a la hora de desarrollar, donde se hacen más dobles checks a nivel de calidad de código, que si bien antes hacía, ahora le doy más énfasis y tiempo a la implementación y ejecución de estas mejoras. Además, me ha ayudado a clusterizar/modularizar mejor la forma en que ataco determinados proyectos.”

Conclusiones

Para finalizar, es crucial mantener estos estándares a medida que crecemos, para asegurar que nuestros usuarios disfruten de una experiencia fluida con el producto. Sin embargo, también es importante conservar la agilidad para resolver problemas rápidamente si algo falla. Ninguna startup (ni empresa) está libre de errores, incluso las más grandes como Google o Microsoft (como vimos hace unos días). Nuestro objetivo es que, en caso de fallos, podamos corregirlos rápidamente sin afectar otros procesos esenciales, gracias a que estamos siguiendo estas normas establecidas.

Si te preguntas como monitoreamos que lo que definimos se vaya cumpliendo, próximamente lanzaremos un post de cómo comenzamos y hacemos code reviews.