Deuda técnica no significa caos. El caos reina en la inmensa mayoría de los proyectos de software por muchos motivos: prisas (reales o infundidas), falta de conocimiento y habilidades, falta de recursos, equipos disfuncionales, negligencia, cultura empresarial inadecuada/disfuncional…

No existe el proyecto perfecto, siempre hay puntos que se pueden mejorar. En mi experiencia el problema está cuando ya nos damos por vencidos y dejamos que el caos siga reinando y creciendo, o cuando nos vamos al otro extremo pretendiendo que el proyecto sea perfecto, ideal.

Mi entendimiento de la artesanía del software lleva implícito el pragmatismo, nunca pierde de vista que desarrollamos soluciones a problemas concretos y que debemos de buscar las alternativas más viables en cada contexto: más económicas, con el menor “time to market” posible, más sostenibles, durables en el tiempo, con la mayor calidad posible. Es un continuo balanceo entre intereses y principios. Si pretendemos construir un proyecto perfecto, de libro, desde el punto de vista de las mejores prácticas de ingeniería, es fácil que caigamos en parálisis por análisis. Es fácil que dediquemos demasiado dinero a matizar aspectos que no van a retornar la inversión. Lo peor que nos puede pasar es que tardemos tanto en poner el producto en el mercado y sea tan caro que la oportunidad se esfume. Esto lo he visto con mucha frecuencia en proyectos en los que he trabajado, bien por cuenta ajena o bien por cuenta propia, con mi propio dinero (con mis propios emprendimientos de producto). Cuando lanzamos MavenCharts, nuestra startup en 2010, gastamos el poco dinero que teníamos desarrollando un producto fabuloso con gran cantidad de funcionalidades (features) que nunca se llegaron a usar, porque se nos terminó la financiación y la energía al poco de lanzar a producción y ver que nadie lo usaba. Podríamos haber validado mucho antes que mucha menor funcionalidad.

¿Estoy diciendo que hay que desarrollar a toda velocidad y olvidarse de las buenas prácticas? Negativo. Todo el software que escribimos debe ser sostenible, lo cual implica que está cubierto por test. Eso como mínimo. Cuando se tiene soltura con los test y se conocen los principios de código sostenible, no cuesta más caro aplicarlos. Donde podemos ahorrar es en optimizaciones y automatizaciones prematuras. También podemos ahorrar en aprender tecnología nueva, escogiendo lenguajes y frameworks bien conocidos (por eso prefiero stack JVM o .Net). Si pretendemos sacar el producto a la vez que aprendemos a usar el nuevo lenguaje que nos apetece, o que nos han dicho que es lo mejor, y el nuevo framework de moda, vamos a gastar demasiado dinero. No podemos estar semanas preparando pipelines, definiendo procesos magistrales, tuneando los últimos frameworks del mercado, preparando el sistema para una escalabilidad descomunal, para alta disponibilidad… para cosas que no hacen falta hasta después de que el producto está en uso y de verdad se justifican.

Y esta es la deuda técnica planificada: todos aquellos elementos que el software necesitará en algún momento, si el proyecto tiene éxito, pero que ahora mismo nos frenan velocidad para salir a producción. El enfoque lean busca la entrega continua (continuous delivery) sin perder de vista que aquello que construimos es sólido y está bien construido, para no volver a trabajar sobre lo mismo. Buscamos una cadencia constante de entrega de producto. Si el objetivo final fuese hacer un coche de Formula 1, lo entregaríamos en fases: primero construimos un patinete, luego un triciclo, luego un carro… de manera que cada entrega tiene alguna utilidad. Esto es muy diferente a invertir meses construyendo una rueda perfecta para el Formula 1. Con la estrategia del patinete podemos ir a la pista a pasearnos con nuestro patinete desde temprano, aprendiendo de lo que nos encontramos en el terreno para construir las siguientes versiones. Con la estrategia del neumático perfecto, solo podremos mirar a la pista soñando con el día que tengamos todo el coche para pasear por ella. ¡Pero tal vez el negocio consista en hacer carreras de patinetes!

La utilidad de los productos digitales es tan incierta que hasta que no se ponen a funcionar y la gente los valida no sabemos si de verdad tienen sentido. Incluso para resolver problemas viejos y bien conocidos, siempre hay mil soluciones posibles. Las optimizaciones, las automatizaciones y las modernizaciones tecnológicas han de venir cuando estamos teniendo tanto éxito con el producto que para seguir creciendo es imprescindible introducirlas. Ahora bien, si el producto no está bien construido (por ejemplo, cuando no tiene test automáticos de respaldo), no podremos introducir esas mejoras imprescindibles para la supervivencia o evolución del producto. En cada iteración o ciclo de desarrollo tenemos que ir pagando deuda técnica vieja y añadiendo o planificando deuda técnica nueva. Hay que ir haciendo pequeñas mejoras de manera constante, como por ejemplo refactorizar un poquito cada día. Equilibrando en todo momento los distintos intereses y necesidades.

En el día a día de los proyectos siempre se aprende, sobre todo de compañeras y compañeros con más experiencia. Es inevitable aprender al hacer y es deseable. Sin embargo, a los proyectos hay que sumarse sabiendo hacer. Stakeholders/inversores no pagan para que la gente se forme, sino para que produzca. Por eso, en Lean Mind ponemos tantísimo énfasis en la formación y el entrenamiento en forma de code katas, pet projects y tareas de aprendizaje donde no haya deadlines ni se juegue el dinero de clientes. La empresa reserva un tiempo para la formación, dentro del horario laboral, de manera que en los proyectos aplicamos lo que ya hemos probado que funciona.