Últimamente ando enfrascado en conversaciones interesantes sobre desarrollo de software, empezamos con la discusión sobre metodologías y frameworks, luego hablamos de tests.
En esa conversación uno de los principios ágiles que fue mencionado es:
«Continuous attention to technical excellence
and good design enhances agility.»
El problema surge sobre lo que es la excelencia, quizás sobre esto tenemos visiones distintas.
Yo creo que la excelencia no es una propiedad del software aislado del contexto. Me explico, un sistema con triple cifrado más doble autenticación más 4 códigos de verificación de las integridad que está lleno de tests, y bien documentado. Que también sigue los mejores patrones de diseño y que ha sido refactorizado varias veces…. Puede ser una excelente pieza de software salvo que todo eso no fuera necesario.
Es verdad que el manifiesto dice que la entrega de software que funciona es la principal guía para el avance. Pero eso tiene que aportar valor de negocio.
No basta, además con aportar valor, hay que aportar más valor de los que cuesta producirlo. Parece una obviedad pero yo creo que a mucha gente ser le olvida. Por no hablar de qué es más importante el valor percibido que el aportado (otro post).
En ese contexto el artículo que recomendó:
El otro día @jmbeas decía que si el software no tiene tests se puede decir que no fue construido ágilmente, y yo discrepo un poquito: https://t.co/1Iy80MRu2p
— Agustin Cuenca (@agustincnc) June 3, 2019
Es claro que hacer mal software tiene coste as largo plazo, y no voy a ser yo quien lleve las contraria al Sr. Fowler. Pero en ese mismo artículo está bien claro que al principio del proyecto es más caro hacer el software «cómo dios manda».
Y también está claro que eso al final se paga. Pero yo creo que la solución no es perseguir la excelencia técnica de las primera línea de código.
Yo creo que en un proyecto que arranca los tests al principio son un cierto desperdicio. El proyecto en las primeras fases tiene un enorme nivel de incertidumbre, y creo que la mejor manera de resolverlo es salir a probar en real lo antes posible (Siempre que el coste del error lo permita #otropost 😉 ), y una vez el mercado te ha dicho si el proyecto está bien o no, entonces es el momento de invertir en tests.
Es decir, yo creo que el problema no es si debemos hacer tests o no, el problema es cuando debemos hacerlo, y yo creo que se debe invertir en tests y mejorar la calidad de tu código una vez el proyecto tiene un cierto grado de estabilidad.
Es verdad que no hacerlo deteriora la “excelencia” de tu código, pero creo que la excelencia tiene que ver con el contexto. Y en muchos proyectos la “excelencia” técnica es un lujo que un equipo con pocos recursos no se puede permitir.
La clave está en no olvidar que la deuda técnica que adquieres (y no escribir tests ayuda a que la deuda técnica crezca) hay que pagarla.
Siempre me ha gustado la metáfora de la deuda técnica, se parece mucho a la deuda de una empresa.
Todos pensamos que endeudarse es un error, y que sería mejor no hacerlo, pero en cuanto sabes un poco de finanzas entiendes que el nivel de endeudamiento es una de las magnitudes mas relevantes que se deben gestionar, e igual con la deuda técnica, endeudarse por las razones equivocadas es un error, igual que lo es no recurrir a la deuda porque endeudarse es malo.
Yo creo que no está mal que un proyecto arranque generando deuda técnica, a veces no tienes dinero para no hacerlo. Y por lo tanto la deuda técnica hay que gestionarla y ser conscientes de que lo que estás haciendo te va a costar ( y puede que no te guste el tipo de interés).
El error es no tener en cuenta la deuda técnica, ignorar que el software que no persigue la excelencia es mas caro a largo plazo y pensar que da igual 8 que 80.