Estaba pensando en una investigación que hace mucho dejé de lado, pero que he decidido retomar. El triángulo de hierro está involucrado y también una presentación que hice hace 9 años (!@#!@#! estamos envejeciendo)
Tenemos que aceptarlo, hace mucho que la calidad ha pasado a un segundo o tercer plano debido a la posiblle confusión generada por la agilidad y la necesidad del negocio porque es “transparente”, “ya debería venir”, “no habíamos pensado en eso” o bueno, “es una caja negra”, cuando en realidad es un factor crucial para el éxito en un proyecto.
Pero bueno, voy a darle una mirada a esa presentación que hice en Microsoft Perú por esa época, estoy seguro que muy pocos la recuerdan. También estoy seguro que mis chistes fueron malos, Pero diablos, tanto tiempo y esa ppt tiene cosas que siguen caladas en mi ser!
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:
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.
McConnell y Fowler clasifican las causas como deliberadas, por desconocimiento o incluso ingeniudad.
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.
La deuda se debe mitigar de a pocos ni bien se vaya identificando. Sería ideal eliminarla pero casi nunca es así.
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”
