Deuda técnica

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

La deuda técnica, también conocido como deuda de diseño o deuda de código, es un concepto de desarrollo de software que hace referencia a los costos de un esfuerzo adicional causado por la elección de un desarrollo sencillo y apresurado en lugar de usar un mejor enfoque que tomaría más tiempo.

Definición[editar]

El sector informático presenta la particularidad de que permite la implantación de productos no acabados o con errores conocidos. En ocasiones, la política de ahorro de costes en la implantación de hardware o el desarrollo de software se centra en recortar los procesos de pruebas, control de calidad o documentación, o incluso algunos parámetros básicos de optimalidad de procesos, lo que compromete la viabilidad a largo plazo del proyecto a cambio de poder entregarlo en el plazo previsto y con el presupuesto acordado.

Causas[editar]

  • Definición previa insuficiente. Ocurre cuando los requerimientos continuan siendo definidos durante el desarrollo y el proceso de construcción da inicio antes de ser diseñado.
  • Presión del área de negocio. Cuando el área de negocio considera que se debe liberar el desarrollo antes de que todos los cambios necesarios sean completados, generando así una deuda técnica.
  • Falta de procesos o entendimiento. Cuando el área de negocio desconoce el concepto de deuda técnica y toman decisiones apresuradas sin considerar las implicaciones.
  • Componentes fuertemente acoplados. Ocurre cuando las funcionalidades no son modulares y la solución no es lo suficiente flexible para adaptarse a las nuevas necesidades de negocio.
  • Falta de una batería de pruebas, que propicia el uso de parches improvisados y riesgosos para corregir errores de código.
  • Falta de documentación, cuando se escribe código sin la documentación adecuada de soporte. El esfuerzo que representa la generación de documentación representa una deuda que debe pagarse en algún momento.
  • Falta de colaboración, cuando el conocimiento no es compartido dentro de la organización y la eficiencia del negocio se tambalea o los desarrolladores junior no están capacitados adecuadamente.
  • Desarrollo en paralelo en dos o más ramas incrementa la deuda técnica ya que el trabajo requerido para fusionar los cambios en una sola línea base de código. Entre más cambios se realicen de manera aislada más incrementa la deuda.
  • Posponer la refactorización. A medida que los requerimientos del proyecto evolucionan las partes de código que se han vuelto ineficientes y dificiles de editar deben ser mejorados (refactorizados) para poder soportar futuros requerimientos. Entre más tiempo se posponga la refactorización y más código sea agregado más grande será la deuda.
  • Falta de alineación a los estándares, ocurre cuando los estándares de la industria, las tecnologías y los marcos de trabajo son ignorados.
  • Falta de conocimiento, cuando los desarrolladores simplemente no saben como escribir código elegante.
  • Falta de pertenencia, cuando los esfuerzo del desarrollo de software realizado por terceros necesita ser refactorizado o reescrito por los desarrolladores internos.
  • Liderazgo técnico pobre, ocurre cuando se toman decisiones mal pensadas y éstas se transmiten a través de la cadena de mando.
  • Cambio de especificación de último minuto, estos tienen el potencial de filtrarse a lo largo de un proyecto, pero no hay tiempo ni presupuesto para llevarlos a cabo con la documentación y los controles necesarios.

Consecuencias[editar]

El resultado de esta política implica que el desarrollo del software se prolonga en el tiempo más allá de la entrega del producto supuestamente concluido; incluso en ocasiones son distintos equipos de desarrollo los que acaban haciéndose cargo de las mejoras. Si el proyecto estaba delimitado en fases, la subsanación de errores de las fases más tempranas se solaparía con el desarrollo de las siguientes fases, lo que dificulta llevar a buen término ambas tareas. Lo mismo es aplicable para el despliegue de hardware o tareas equivalentes.

Origen del término[editar]

El término deuda técnica fue propuesto por primera vez en 1992 por Ward Cunningham. Un desarrollo pobre, tal y como se describe en el párrafo anterior, equivale a una evaluación de inversiones financieras basada en la obtención de beneficios a corto plazo. En el sector de las finanzas, una inversión que busca el beneficio a corto plazo puede generar deudas cuyos intereses se han de liquidar durante un período de tiempo muy prolongado. De forma análoga, un desarrollo tecnológico aparentemente corto puede requerir un esfuerzo extra para subsanar los problemas generados al no aplicar los consejos básicos de desarrollo. Ese esfuerzo extra, que puede multiplicar el tiempo de desarrollo del proyecto inicial, equivaldría a los intereses de una deuda financiera.

Véase también[editar]

Enlaces externos[editar]