Permítanme comenzar con la definición original y luego explicaré cómo las personas están utilizando el término hoy en día.
Ward Cunningham, coautor del Manifiesto Ágil que acuñó el término "deuda técnica", lo explicó con una metáfora financiera: “Avanzar en el desarrollo de una nueva aplicación de software es como obtener un préstamo (deuda).”
Imaginen construir un producto utilizando una tecnología completamente nueva. Se enfrentan a muchas incógnitas. Hacen lo mejor que pueden con lo que saben en este momento. A medida que descubren qué está funcionando bien y qué no, utilizan ese conocimiento para mejorar el código. Mejorar el código a medida que aprenden de la experiencia es similar a pagar el préstamo.
En los últimos años, sin embargo, la definición de deuda técnica ha evolucionado. Hoy en día, la mayoría de los equipos piensan en la deuda técnica como código con deficiencias e ineficiencias conocidas, pero si no está deteniendo el proceso, está bien dejarlo ahí.
¿La búsqueda de entregas más rápidas está causando más deuda técnica?
Centrarse en entregas rápidas puede resultar en recortes en la calidad del código. La idea de que: “Si no es perfecto, podemos arreglarlo en la próxima versión.”
La deuda técnica puede acumularse de esta manera. Como los desarrolladores necesitan completar nuevas características y mejoras, pueden no tener tiempo en sus agendas para corregir el código de versiones anteriores.
Si un equipo no tiene tiempo para escribir un código limpio en primer lugar, ¿por qué tendrían tiempo para hacerlo después? Si nunca regresan para mejorar el código, permiten que la deuda persista y crezca. Están pagando intereses sobre ello.
¿Cómo afecta la deuda técnica a la seguridad?
Para alcanzar las metas de entrega, los equipos pueden lanzar códigos con vulnerabilidades de seguridad evidentes. Una vulnerabilidad es cualquier debilidad que pueda llevar al compromiso de datos, sistemas, reputación de marca, etc. Un riesgo de seguridad de TI se refiere a las posibles consecuencias que una empresa puede enfrentar si un atacante explota exitosamente esas vulnerabilidades.
Los equipos deben equilibrar la búsqueda de velocidad con los factores de funcionalidad, usabilidad y seguridad. Desafortunadamente, a menudo estas prioridades entran en conflicto.
Y si un equipo no prioriza la seguridad desde el principio, ¿qué pasa cuando hay una cultura de “necesidad de actuar rápido, entonces lo arreglaremos después”? Al igual que en los autos, la velocidad mata.
¿Quién es responsable de la seguridad de la aplicación?
La seguridad sigue siendo una reflexión tardía para muchos equipos de desarrollo de software. Pueden verla como la responsabilidad de otra persona y/o algo que ocurre más tarde en el ciclo de vida del desarrollo de software. El trabajo de un programador "normalmente" sería programar. Esta persona a menudo no es un experto en seguridad. Para escribir código con seguridad en mente, los desarrolladores de software necesitan capacitación en principios de codificación segura.
Muchos equipos no tienen material de capacitación para sus programadores con conocimientos o no establecen requisitos de seguridad integrales al inicio del proyecto, incluso si una falla temprana en la seguridad puede causar un riesgo significativo para el negocio.
¿Qué problemas de seguridad puede causar la deuda técnica?
Los problemas más comunes involucran la fuga de datos, eliminación de datos, y dependiendo del tipo de sistema, puede causar grandes daños financieros o para la vida de las personas.
Si el código tiene vulnerabilidades, la manera de hacerlo seguro es refactorizar para corregir las vulnerabilidades. De lo contrario, los problemas de seguridad permanecerán ahí. Poner algo en deuda técnica es similar a aplicar un vendaje en una herida. El vendaje puede darle tiempo para ir al médico, pero no arregla la lesión.
El enfoque en la velocidad puede terminar costando más de lo que cualquier ventaja que pensaron que ganaron.
Dejo una analogía: "Consideren la deuda técnica como la deuda con un prestamista, siempre es mejor pagar antes de que venga a cobrar".
Top comments (0)