El coste de la deuda técnica: $3.61 por línea de código fuente

Se suele denominar deuda técnica a problemas/deficiencias en una base de código que no hacen que ahora mismo ese código no funcione de modo adecuado o no están causando un problema de modo inmediato, pero que con alta probabilidad causarán un problema en el futuro cuando, por ejemplo, haya que extender la funcionalidad de esa pieza de código.

El nombre de deuda técnica viene de que los programadores han tomado atajos a la hora de crear ese código "tomando prestado tiempo del futuro", ya que en el futuro deberían refactorizar el trabajo que han hecho de modo incorrecto y "pagar esa deuda".

CAST software ha hecho por segundo año consecutivo un estudio sobre la deuda técnica de proyectos de software, estudiando un total de 745 sistemas que combinados acumulan 365 millones de líneas de código. Los principales hallazgos de este estudio son que:

• Estiman que cada línea de código acarrea un coste de $3.61 para la organización que tiene que mantenerlo, coste que se traduce en tiempo y recursos que habrá que invertir en el futuro en remediar los "atajos" tomados a la hora de crear el código.
• Un 35% de los elementos que fueron considerados como "deuda técnica" podrían resultar potencialmente en problemas de seguridad, rendimiento, o provocar downtime.
• La deuda técnica es similar en proyectos desarrollados "in-house" y mediante outsourcing.
• Los proyectos Java EE fueron los proyectos que tenían una deuda técnica mayor.
• Cuando se emplean metodologías de desarrollo de software establecidas como técnicas ágiles o "waterfall", la calidad del software resultante superior a que si se emplean técnicas desarrolladas dentro de la organización.
• COBOL es el lenguaje que obtuvo mejores métricas en seguridad, y .NET el que obtuvo peores métricas en este campo.
• Con cuanta más frecuencia se pone código en producción, más grande suele ser la deuda técnica.

Aquí tenéis un video discutiendo este tema creado por CAST software:

Aquí tenéis otro video muy simpático creado por la compañía explicando el concepto de deuda técnica:

Y aquí tenéis otro video muy simpático sobre los "Scrum Masters", también conocidos como "Software Whisperers" :)

Comments

[choces]

Que una empresa que vende productos de análisis, publique resultados que favorezcan y justifiquen su presencia en el mercado, no tiene nada de extraño.

Lo que no me queda nada claro, porque evidentemente no lo publican, es con qué criterios y métodos llegan a ese tipo de conclusiones.

Este asunto me ha recordado un persistente "aviso" por parte de una herramienta, PMD, con respecto a ciertas secciones de código: insiste en considerar que determinados Prepared Statement son inseguros con respecto a SQL Injection, porque la variable que contiene el comando SQL no es estática.
Lo que la herramienta "ignora" es que esas variables son locales al método que las usa, y que, todavía peor, son construidas en función de determinados parámetros, dentro del mismo método, lo que las hace totalmente invulnerables a SQL Injection.

¿Quién vigila a quien vigila? :D
No creo que haya que dar un crédito absoluto a herramientas, en el sentido de convertirlas en un nuevo Oráculo de Delfos. También las herramientas pueden "equivocarse".

[Abraham]

Sin duda, su informe tiene un parecido con los típicos informes de seguridad que suelen hacer las compañías de antivirus, y probablemente exageren. Pero no creo que no todo, ni mucho menos es exageración. Y los videos que hacen son muy simpáticos :)

[choces]

En cualquier análisis, por interesado que pueda ser, hay un fondo de veracidad.
A principios de Diciembre se hizo una "campaña" en el desarrollo de OpenJDK 1.8 para reducir el elevado número de warnings de compilación, que ya rebasaba los 10.000
La inmensa mayoría son heredados de versiones anteriores, porque no se han hecho cambios tan sustanciales en el código base.
En una semana se redujeron a unos 7.500, y hay otra "campaña" en marcha, liderada por el JUG de Londres (miembro del Comité Ejecutivo del JCP), para reducirlos todavía más.
Si se computan todos esos warnings como technical debt, en el sentido de ese informe, daría la impresión de que la estabilidad del OpenJDK estaría más que comprometida, y que costaría un riñón eliminarla.
En realidad, los technical debt en proyectos de código abierto es un espejismo, en su mayor parte, y tampoco pueden servir para asegurar nada sobre la estabilidad o la seguridad del producto.
Lo que sí se ha conseguido con esa reducción de warnings, es mejorar sustancialmente la calidad del código base, y servir de punto de partida para un análisis más pormenorizado de bloques de código, que por su antigüedad, merecían una revisión con criterios más modernos.
Por ejemplo, se han eliminado, literalmente, decenas de clases que simplemente no se utilizaban.