En el análisis del primer elemento a tener un cuenta un programador en 97 Things Every Programmer Should Know pretendo analizar los siguiente elementos:
- Concepto de Deuda Técnica (DT)
- Reconocimiento de dificultades futuras que puede traer consigo una DT.
- Se suman más problemas: los diferidos, los actuales, y los futuros.
- Seguimiento de la deuda: herramientas, recomendaciones.
- Registro claro de los plazos nuevos de la DT, facilita determinar su coste.
1. Conceto de Deuda Técnica
En términos simples y llanos, se puede considerar a una DT así:
Donde,
TiempoTotalActividad: Es el tiempo total requerido por la actividad (i.e.: refactorización, mantenimiento, extensión funcionalidad, etc) a llevar a cabo.
TiempoHacerloRápido: Es el tiempo que representa la mínima cantidad de esfuerzo para resolver un caso. Nota: siempre TiempoHacerloRápido < TiempoTotalActividad.
La alternativa idónea, y la menos recurrente, por los plazos apremiantes es la que convierte la DT en 0. Dado que TiempoHacerloBien = TiempoTotalActividad.
2. Reconocimiento de dificultades futuras que puede traer consigo una DT.
Conocer o prever las consecuencias que acarrea una DT nos permite determinar las dificultadas futuras en el desarrollo del producto, o durante cualquier otra fase del ciclo de desarrollo (mantenimiento, soporte, etc). ¿Cómo identificar estas dificultades? De manera general, puedo decir que dependiendo de la tarea que estemos realizando; por ejemplo: si se trata de corregir un bug, y se opta por el camino rápido (TiempoHacerloRápido) lo más seguro es que se haya recurrido a crear código spaghetti (ya es evidente que tendremos trabajo adicional, no sólo entiendo el fragmento de código, sino la formulación de una solución alternativa para el problema).
3. Se suman más problemas: los diferidos, los actuales, y los futuros.
TiempoHacerloRápido: Es el tiempo que representa la mínima cantidad de esfuerzo para resolver un caso. Nota: siempre TiempoHacerloRápido < TiempoTotalActividad.
La alternativa idónea, y la menos recurrente, por los plazos apremiantes es la que convierte la DT en 0. Dado que TiempoHacerloBien = TiempoTotalActividad.
2. Reconocimiento de dificultades futuras que puede traer consigo una DT.
Conocer o prever las consecuencias que acarrea una DT nos permite determinar las dificultadas futuras en el desarrollo del producto, o durante cualquier otra fase del ciclo de desarrollo (mantenimiento, soporte, etc). ¿Cómo identificar estas dificultades? De manera general, puedo decir que dependiendo de la tarea que estemos realizando; por ejemplo: si se trata de corregir un bug, y se opta por el camino rápido (TiempoHacerloRápido) lo más seguro es que se haya recurrido a crear código spaghetti (ya es evidente que tendremos trabajo adicional, no sólo entiendo el fragmento de código, sino la formulación de una solución alternativa para el problema).
3. Se suman más problemas: los diferidos, los actuales, y los futuros.
Responsabilizarse de una deuda técnica representa una carga de trabajo exhaustiva (varía, desde luego, dependiendo de la complejidad de la tarea, números de pasos para completarla, recursos requeridos (tiempo, dinero, etc).
4. Seguimiento de la deuda: herramientas, recomendaciones.
La programación de la DT consiste en planificar su solución en un corto plazo. Se recomienda disponer del tiempo aproximado necesario, de coordinación con otros miembros del equipo de trabajo, en cuanto al sistema a mantener, depurar, extender, establecer un horario de solución de incidencias que no afecte la operación por parte de sus usuarios.
5. Registro claro de los plazos nuevos de la DT, facilita determinar su coste.
En caso que sea necesario, podemos posponer la deuda, pero teniendo cuidado en estos aspectos: nivel de prioridad, disponibilidad de recursos, el no cruce con otras actividades futuras, entre otras.
¿Alguna vez han tenido una deuda técnica en la construcción de un producto software?
Reconcimiento:
Autor: Seb Rose
