Cuando empiezas a hacer deporte y no tienes mucha experiencia, al principio lo que parece más importante es exclusivamente el entrenamiento. Por lo tanto, cuanto más entrenas, mejor.

Con el tiempo aparecen los problemas en forma de lesiones. Y es entonces cuando a través de la experiencia de otros que se han lesionado antes o la tuya, empiezas a entender que el ejercicio físico no es lo único importante.

Hay otros pilares junto con el entrenamiento que son la nutrición y el descanso. Estos 3 pilares entrenamiento, nutrición y descanso necesitan ser de alta calidad y en estar en equilibrio. Cuando esto sucede forman un la base sobre la que se apoya un entrenamiento de calidad.

Algo parecido ocurre con el desarrollo de software.

Comportamiento

Al principio, cuando empiezas como desarrollador de software y tienes poca experiencia, tu única preocupación es entregar funcionalidades. Terminar tareas que te asigna un tercero, ya sea un jefe o un cliente directamente.

A este pilar le llamaremos comportamiento, es un pilar fundamental.

El comportamiento es el pilar más visible para los clientes y desarrolladores. Y a veces, tristemente es lo único valorado.

A los usuarios les gusta cuando añadimos comportamiento, si es lo que quieren. Pero si cambiamos o eliminamos el comportamiento del que dependen, introducimos errores, dejan de confiar en nosotros.

Lo peor que nos puede ocurrir como developers es cuando dejan de confiar en nosotros.

Una de las mejores prácticas que conozco para entregar comportamiento esperado y sin malas interpretaciones es que negocio sea partícipe del desarrollo y este se desarrolle en ciclos cortos e iterativos. De esta forma se puede ir ajustando y adaptando cambios en los requisitos o malos entendidos, ya sea porque el cliente no sabía bien lo que quería hasta que lo ve o nosotros no entendimos bien el problema a resolver.

Si nos centramos exclusivamente en el pilar del comportamiento, con el tiempo aparecen problemas en forma errores, dificultad para mantener el código y dificultad para escalar.

Esto deriva también en falta de confianza del cliente.

Fiabilidad

Otro motivo por el que pueden dejar de confiar en nosotros es la falta de fiabilidad. Con esto me refiero a entregar comportamiento que funciona al principio, pero deja de funcionar con el tiempo debido a situaciones no contempladas o probadas.

El pilar de la fiabilidad es algo que se da por hecho por parte del cliente. Por ejemplo, cuando te compras un coche, esperas que funcione y si al poco tiempo deja de funcionar por fallo de motor, pierde fiabilidad y nosotros como cliente perdemos confianza en el producto.

Lo mismo ocurre con el software que entregamos, si deja de funcionar de repente por algún motivo o en algún escenario menos habitual, el cliente pierde confianza en nosotros.

En este caso, además de ciclos cortos de desarrollo, trabajar con feedback temprano es muy importante. Si el feedback debido a errores nos lo da el cliente, no es feedback temprano sino demasiado tarde y supone un coste mayor.

Desarrollar usando test automáticos e integración continua ayuda a obtener feedback temprano durante el desarrollo, que ayuda a detectar problemas antes de entregar software al cliente.

Fácil de cambiar

Existen motivos por los que el software debe ser cambiado una vez entregado al cliente.

El cliente nos puede solicitar añadir una característica nueva, modificar una existente o nos informa de un error en el sistema.

Poder realizar el cambio en un tiempo acorde al cambio solicitado y no acorde a lo difícil que sea de cambiar el código, es fundamental para que el cliente no pierda la confianza en nosotros.

El cambio también puede nacer de nuestro lado. Si se detectan problemas de consumo de recursos que derivan en problemas de rendimiento, necesitaremos optimizar el consumo de recursos. En ocasiones, es necesario mejorar una parte del diseño del software con el objetivo de poder realizar modificaciones futuras de forma más simple.

La velocidad en avance de la tecnología, es otro motivo de cambio en el software. Deberemos actualizar frameworks y librerías con el paso del tiempo. Estas librerías podrían traer breaking changes que no debería ocasionar un drama en nuestro código.

Al realizar cambios en el software, contar con una red de seguridad de tests que nos indique si estamos rompiendo comportamiento ya existente de forma involuntaria es fundamental. Además, es importante usar técnicas como el refactoring, donde se realizan los cambios en pequeños pasos seguros.

El cambio es inevitable, que el software esté estructurado de forma que sea fácil de cambiar, es fundamental para tener software escalable y estable.

Que el software sea fácil de cambiar es el último pilar para conseguir tener un software de calidad.

Conclusiones

Cada uno de los pilares individualmente es importante que se encuentre en niveles altos de calidad y en conjunto en equilibrio.

La calidad del software decrece cuando uno de los pilares se tambalea, lo que deriva en perdida de confianza del cliente en nosotros.

No es posible tener software de calidad si falta alguno de estos pilares.

Tener una buena arquitectura de software, ayuda a mantener estos pilares en niveles altos de calidad. La arquitectura son los cimientos sobre los que construir estos pilares.

Te puedes apuntar a la lista de espera de la próxima edición en abierto del Curso de Clean Architecture:

Curso Clean Architecture en abierto - Lista de Espera

¿Te ha gustado esta newsletter?

El mejor regalo de agradecimiento que me puedes hacer es compartirla 👇

Te animo a que me des tu opinión, o me transmitas dudas en los comentarios de esta newsletter desde la web o respondiendo a este correo.

A veces tardo, pero siempre acabo contestando.