No llevo demasiado tiempo en el mundo del desarrollo de software, pero algo con lo que me he podido topar y ver delante de mis ojos son con gestiones de proyectos que han ido adquiriendo una deuda técnica para cumplir con los tiempos marcados produciendo un software que se ha vuelto casi inmanejable. El concepto de deuda técnica comenzó en el desarrollo hace algunas décadas y es muy conocido a día de hoy. Personalmente he leído algunos artículos sobre este concepto y os recomiendo algunos escritos en el blog de Javier Garzas.
¿Qué es la deuda técnica?
La deuda técnica es “un concepto en el desarrollo software que indica la cantidad de trabajo de desarrollo adicional que se va acumulando cuando se implementa código que es fácil de desarrollar a corto plazo en lugar de aplicar la mejor solución global”.
Básicamente viene a decir que pagarás aquellas soluciones temporales que incluyas en un desarrollo sin tener en cuenta una visión global y de crecimiento de tu software. En el desarrollo del software se debe de valorar la mantenibilidad y la capacidad de evolucionar de este aplicando buenas prácticas de desarrollo
En la siguiente matriz de Philippe Kruchten (si no me equivoco) se expresa donde podemos encontrar la deuda técnica en un desarrollo software. También otros grandes conocidos del desarrollo de software como Martin Fowler se han pronunciado sobre este concepto.
Típicamente se suele comparar la deuda técnica con un iceberg, ya que cara al usuario que usa el software es probable que la deuda técnica sea totalmente transparente para él (punta del iceberg), sin embargo los desarrolladores y dueño del producto deberían de tenerla muy presente en su día a día y en los enmarañados del software (parte oculta).
En todo proyecto es lógico acumular una cantidad de deuda técnica, ya que se considera necesaria para sacar proyectos adelante y cumplir con las expectativas del dueño del software de una manera ágil. Por lo que tampoco hay que caer en la sobre ingeniería, y saber trabajar con esta deuda presente sacando el proyecto de una manera exitosa.
¡ESO SI! Lo que hay que mantener siempre esta deuda es bajo control y aplicar técnicas para reducirla\mantenerla cuando un software crece. Un exceso de deuda técnica produce un mantenimiento complicado y una gran dificultad de implementación de nuevas features a medio plazo, frustrando tanto a la gente de negocio como a los developers. Los expertos también lo ven como una necesidad y proponen acumular una deuda que se vaya controlando a corto plazo y cuidarla en cada sprint o iteración [decida aquí su metodología].
Causas que aumentan la deuda técnica
Existen muchos motivos por los que vamos subiendo nuestro contador de deuda técnica, muchos de ellos por temas de negocio, ya que vivimos en una sociedad que evoluciona con gran velocidad y básicamente todo se necesita para ayer. Vamos a conocer algunas causas principales que pueden aumentar la deuda técnica.
- Presiones del negocio: En general todo debe ser lanzado cuanto antes y muchas veces se sacan cosas a producción sin haber pasado un buen control de calidad y con cambios rápidos que no contemplan todas las posibilidades o no totalmente completos.
- Cambios en la especificación: Es común que las especificaciones también a mitad del desarrollo e incluso en el último momento (sufrido en mis propias carnes). Este tipo de cambios generalmente se incluyen en el proyecto con soluciones pobres o como se dice comúnmente con calzador. En general no hay tiempo o presupuesto para hacer las comprobaciones adecuadas para este tipo de cambios. (Por favor, gente de negocio no cambiéis el core del negocio una semana antes de subir a producción)
- Falta de buenas prácticas: Por ejemplo se decide no emplear un sistema de integración continua, prescindir de una batería de tests, no invertir tiempo en refactorizar, no diseñar una buena arquitectura con componentes muy aplicados que no se adapten a los cambies [incluya aquí una larga lista de malos hábitos que vea en su empresa].
- Falta de conocimiento: Vivimos en un país en el que muchas empresas prefieren sacar adelante un proyecto adelante con becarios o gente con poca experiencia que quizás no escriban un código muy elegante. Es importante disponer de buenos recursos con experiencia en desarrollo software (senior) y que este tipo de roles colaboren para enseñar a developers con menos experiencia (junior). En mi humilde opinión, hay que dar oportunidades a la gente joven y apostar por el talento y gente con experiencia. Por favor, que no te haga la web tu cuñado.
- Falta de colaboración: A veces se toman malas decisiones por no conocer el negocio en profundidad, sin considerar ciertas implicaciones y por que la gente de negocio no se involucra lo suficiente en el desarrollo. Para ello aplicar DDD (Domain Driven Design) y seamos un solo equipo.
- En algunos casos se incluyen influyen aspectos como el outsourcing, en el que empresas ponen sus esfuerzos en legar resultado y no en el cuidado del software. Yo por mi experiencia y lo que he podido ver estoy a favor de desarrollar el software in-house e intentar externalizar minimamente, pero eso ya son decisiones de negocio.
Conclusión
Mantén a raya tu deuda técnica, no apliques una refactorización tardía y aplica este proceso con una frecuencia alta y siempre intentando aplicar buenas prácticas de desarrollo software, puede que cuando te quieras dar cuenta no haya marcha atrás y tengas que tirar todo tu software a la basura y empezar de cero.
