¿Qué entendemos por calidad en un proyecto software? ¿Es posible que el exceso de calidad esté perjudicando al proyecto? ¿Somos demasiado extremistas con la calidad? Este es un tema recurrente que, de tanto en tanto, sale a discusión entre agilistas y no agilistas, a veces con críticas poco constructivas al movimiento de la artesanía del software.

Lo cierto es que en toda mi carrera profesional, jamás vi un proyecto que sufriera retrasos o pérdidas económicas por haber invertido en lo que yo considero calidad. Por ejemplo:

• Una buena batería de test automáticos de respaldo.
• Usar alguna herramienta de análisis estático de código, tipo Sonar, y corregir los issues que el equipo considera de mayor retorno de inversión.
• Tener un documento de convenciones con los estandares de programación en el equipo.
• Definir una arquitectura adecuada para la solución.
• Trabajar en pares o en grupo, sobre todo para problemas complejos.
• Pensar antes de programar, para hacer un código más sencillo.
• Practicar refactoring a diario, ordenando y limpiando el código de forma constante.
• Realizar sesiones de exploratory testing antes de cada release.
• Disponer de un sistema de integración continua que construya y despliegue de forma automática para evitar errores humanos.
• Instrumentar el código para medir rendimiento, registrar errores, aprender de los usuarios...

Todos estos elementos y muchos más, son para mí componentes de la calidad. Son característicos de nuestra forma de trabajar y forman parte del proyecto desde su inicio. Como decía William Edward Deming, la calidad no puede añadirse a posteriori, sino que debe formar parte del proceso desde el inicio. No solo es que la calidad no va a penalizarnos, sino que será la que aumente nuestra productividad. Nos permite conseguir resultados homogéneos, predecibles, acorde a estándares de la industria y a los nuestros propios. La calidad es parte de lo que nos define como profesionales y nos permite sentirnos orgullosos del trabajo bien hecho, pero, además, es la única forma que hemos encontrado de que el software que construimos sea sostenible en el tiempo.

Seguro que muchas personas se sienten cómodas con esta visión de la calidad, entonces ¿por qué surge la discusión en torno a la calidad? En mi experiencia, es porque llamamos calidad a cosas que no lo son, como, por ejemplo, el dogmatismo y la falta de conocimiento técnico y de pragmatismo. A continuación, se nombrarán algunos ejemplos concretos de decisiones que sí impiden el desarrollo de un proyecto y que supuestamente son en nombre de la calidad:

• Desarrollar un MVP de un producto que va a ser pequeño y con pocos usuarios concurrentes, con siete microservicios, siete repositorios de código separados, kubernetes y otras herramientas, que ni son necesarias para el MVP, ni probablemente lo sean nunca para este producto.

• Dedicar tres semanas a construir el pipeline de integración continua de los sueños.

• Rehacer la "arquitectura" de la solución tres veces antes de la primera salida a producción.

• Querer meter con calzador la última tecnología de moda, aunque no la sepamos utilizar.

• Querer hacer todo con TDD, cuando nadie del equipo tiene soltura con esta técnica.

• Provocar cuellos de botella con la revisión de código asíncrono (Pull Request/Merge Request), en vez de sentarnos juntos a trabajar y de confiar en los integrantes del equipo, para que cualquiera pueda desbloquear atasques y sumar valor a negocio cuando se necesite. No estoy diciendo que los PR sean negativos, hay muchos contextos en los que son muy útiles, son una herramienta de calidad muy positiva cuando los equipos trabajan en asíncrono, en diferentes zonas horarias, cuando el proyecto es open source, cuando no se practica pair programming... a lo que me refiero es al dogma que he visto en proyectos donde se frenaba el avance del proyecto, la puesta en producción de trabajo realizado de manera recurrente en supuesta defensa de la calidad.

• Intentar copiar las prácticas de desarrollo del equipo de Netflix, de Facebook o Github, aun cuando el contexto de nuestro equipo seguramente no tiene nada que ver con estos. Los procesos de calidad son diferentes para cada equipo, porque el contexto es fundamental para entender la calidad.

• Over-engineering:

  • Implementar OAuth para autenticación en un sistema que no se integra, ni se va a integrar con ningún otro.
  • Dedicar dos semanas a implementar autenticación JWT, cuando se puede hacer una típica basada en cookie de sesión en un día.
  • Usar colas de mensajes, buses de eventos y event stores, para sistemas que van a tener un volumen de escrituras muy reducido y bajo nivel de concurrencia.
  • Hacerte tu propio framework o librería, cuando puedes usar perfectamente algo existente y open source.
  • Usar el lenguaje de programación inadecuado para el problema que tenemos en frente.
  • Usar librerías cuando sería más fácil con lenguaje vanilla y también al revés, reinventar la rueda cuando podrías usar una librería que hace justo lo que necesitas.
  • Esta lista podría contener cientos de elementos, la mayoría de las veces relacionados con introducir mucha más complejidad de la que hace falta en el sistema (complejidad accidental).

• Podríamos enumerar muchos más ejemplos en donde se confunden prácticas fuera de contexto con procesos de calidad.

A menudo, lo que hay detrás de estas decisiones son buenas intenciones, ganas de aportar y de hacer un buen trabajo. Se hacen en nombre de la calidad, pero luego se convierten en decisiones que dañan al proyecto, por varios factores. Uno es la falta de alineamiento en la visión de negocio; si el equipo técnico no entiende bien el plan de negocio, las fases, dónde está el valor, qué es lo importante, entonces no podrá tomar decisiones técnicas adecuadas. Por desgracia, es muy habitual que el equipo técnico esté lejos de los stakeholders, con varias personas en medio que se comportan como actores del teléfono escacharrado.

Otro factor es la falta de conocimiento técnico en los equipos, por ejemplo, cuando todo el equipo está compuesto por juniors que no tienen el apoyo/guía de otra persona técnica con experiencia creando soluciones pragmáticas adaptadas al negocio. Un clásico es cuando quieren escribir test automáticos, pero nunca lo han hecho antes y en lugar de contratar ayuda externa especializada, deciden aprender a golpes, gastando tiempo y dinero del proyecto.

Los egos nos la juegan con frecuencia, todo el mundo quiere demostrar que es profesional y que tiene mucho que aportar a los proyectos, pero a veces el ímpetu nos lleva a introducir problemas, en vez de ayudar. Los egos nos engañan cuando llamamos calidad al dogmatismo o al heroísmo y también cuando criticamos de forma destructiva metiendo en el mismo saco a todo el mundo.

El movimiento de la artesanía de software (software craftsmanship), tal como yo lo entiendo, reivindica que hagamos el software con calidad, con profesionalidad y, por supuesto, con pragmatismo, no con dogmatismo. El dogmatismo se puede detectar cuando la persona que propone una práctica o proceso no sabe explicar de forma clara la ventaja de dicha práctica o proceso, sino que se limita a decir que es una buena práctica de calidad, porque lo dice Bob Martin o cualquier otro autor. Sabernos explicar con claridad es fundamental para reducir esa brecha que hay entre negocio y developers, objetivo que perseguía el manifiesto ágil y que nos vuelve a recordar el manifiesto de la artesanía del software.

Aprovecho para dar las gracias a Javier Martín de Agar, Juan Banda y Ana Carmona, por recordarme que quería escribir sobre este tema desde hace tiempo. Probablemente, este tema sea también motivo para hacer un episodio de podcast.