Si bien es cierto nunca he escrito sobre la deuda técnica, reconozco que cada cierto tiempo reviso o empiezo un nuevo borrador al respecto y lo dejo –con mucho dolor– en la lista de apuntes sin publicar.

Hoy por la noche voy a borrar aquellos apuntes y tengo un sinsabor que aumenta con el paso de los años.

Antes de continuar con ello y para quitarme el clavo, aquí algunos apuntes:

1. Ward Cunningham indica que la deuda está asociada a la programación/reprogramación/corrección que harás más adelante, pues hoy –o ayer– no hiciste un programa sin seguir las recomendaciones, estándares o buenas prácticas de programación y/o arquitectura.
2. McConnell y Fowler clasifican las causas como deliberadas, por desconocimiento o incluso ingeniudad.
3. Por mi parte y considerando que más que software se entrega una solución, pienso que la deuda se debe analizar en todo sentido, en cada capa, etapa, proceso, modelo o secuencia utilizada para la creación del producto.
   • Esto significa que también se debe hacer una mención al hecho de cómo se definen las necesidades de los usuarios o cómo es que se compila, distribuye o instala el software resultante.
   • Tampoco se debe olvidar el prototipado/maquetado de la solución. El cual a veces es olvidado y otras es tan sobrevalorado que hasta llegas a odiarlo.
4. La deuda se debe mitigar de a pocos ni bien se vaya identificando. Sería ideal eliminarla pero casi nunca es así.
5. Para finalizar, creo que para no confundir, la deuda técnica debería cambiar de nombre o al menos de versión, pues la realidad ha cambiado y con tantos nuevos jugadores, debería existir algo así como una “Deuda Técnica 2.0”

Confieso que al terminar de escribir estos cinco puntos, he vuelto a sentir ese sinsabor pues tal como decían aquellos mounstruos de la ingeniería del software (no se molesten aquellos que no los consideren así)

La deuda puede tener causas deliberadas.

¿Y eso que significa?

Lo haremos así porque nos queda poco tiempo. No te preocupes, luego lo arreglaremos.

Y todos sabemos que no es cierto.

Empezamos un nuevo año y estoy seguro de que ustedes –al igual que yo– han definido resoluciones y entre estas siempre hay una que dice “este año lo haremos mejor”, cuando en realidad nosotros no podemos controlar lo que pasa en el mercado, en nuestros trabajos, en el negocio.

Por favor no confundan este sinsabor con pesimismo.

Lo que busco compartir es que, si bien es cierto, no podemos luchar contra esa bola de nieve, lo que debemos hacer –en vez de esquivarla– es subirnos a ella con las herramientas adecuadas, el equipo adecuado y bueno, seguir adelante.

Suena fácil, pero si lo volvemos a revisar, comprenderemos que necesitamos un equipo que además de tener cierta química y capacidad de negociación, debe saber trabajar tanto en conjunto -para cumplir el objetivo- como por separado –para eliminar dependencias– y que además sepa manejar las herramientas necesarias para dominar a la bestia (lo sé, primero dije bola de nieve)

Repito, suena fácil, pero sin aquellas condiciones, las deudas técnicas seguirán formando parte de la naturaleza del software y encontraremos frases muy interesantes como:

• Si es está lento, ponle más memoria.
• Sí, falta algo, pero eso lo solucionamos con un nuevo despliegue.
• Sí, cada uno trabaja por separado pero luego nos juntamos para integrar el código.
• ¿Y si eso se lo damos a un practicante para que vaya aprendiendo?
• Los requerimientos  –historias, funcionalidades, etc– siguen cambiando pero la fecha de entrega se mantiene.
• El alcance no se cambia.
• La fecha tampoco (repetido a propósito porque a veces pasa lo mismo)
• ¿Eso no se hace en cinco minutos?
• Pensé que había un framework que hacía eso.
• Mira, tengo un ejemplo que puedes usar como base. Con eso te tomará menos tiempo ¿cierto?
• No te preocupes, la definición la vemos en el camino.

Sí, estamos en el 2017 y a pesar de haber evolucionado en arquitecturas, metodologías, automatizaciones y demás cosas, el usuario seguirá pidiendo cosas nuevas –es su naturaleza– y nosotros –una vez más– sacrificaremos calidad por fechas de entrega.

La verdad es que la deuda técnica va a cumplir 25 años de haber sido definida y los problemas no se van a resolver de la noche a la mañana. Así que por favor, si pueden imprimir un cartel de LATER IS NEVER, seré muy feliz 🙂

Un abrazo,
JD