Table of Contents
Probablemente, la gente que esté familiarizada con el desarrollo de software conozca el término Deuda Técnica. Es una metáfora brillante traída desde el mundo financiero y que representa el comportamiento, mantenimiento del código y la escalabilidad del tiempo.
Deuda técnica
Cuando sea que estés forzado a dejar algunas partes de tu código con “To Do”, “Refactor” o “Review Later”, eso es una parte adicional de deuda técnica que se adquiere. De este modo, recibes Cash (liquidez) para comprar Time (tiempo). Llegas a la entrega, lanzas el producto a tiempo y dispones de un prototipo para enseñar a un inversor. Pero no te puedes olvidar de los recortes en calidad de código, porque eso es tu deuda técnica. Es algo que debes y has de pagar.
Si, de lo contrario, lo obvias y sigues desarrollando a partir de ahí, tu producto se convertirá cada vez en algo menos estable y el coste de mantenimiento va a subir por las nubes. Para continuar con la analogía más real, es como pedir otro préstamo para pagar la deuda que ya tenias anteriormente, una vez tras otra. Al principio, la cosa parece que funciona, pero esta nunca deja de aumentar para cubrir los intereses y otros gastos, es como una bola de nieve que no deja de rodar colina abajo. Esta es la razón por la cual es importante asignar el tiempo adecuado para refactorizar e incluso muchas veces reconstruir la parte señalada del código.
Aunque estemos familiarizados con la situación, hemos encontrado un atajo para conseguir al mismo tiempo el Tiempo (entrega) y evitar la Deuda Técnica. Pero como resultado, al final, conseguimos una nueva forma de deuda, algo que me gusta llamar Deuda Funcional.
Deuda Funcional
He recogido información para esta idea y he encontrado muy pocas referencias de este fenómeno, y sinceramente, nunca se parece a la idea inicial que yo tenía de ello. En este artículo escrito por Mark Barnes, es descrito como el incumplimiento del principio YAGNI. Cuando escogemos un framework pesado para lo que debería ser ligero y pequeño. Cuando la funcionalidad que ofrece es mayor que la necesitada, el desarrollo y mantenimiento de esos extras se convierte en Deuda Funcional.
Cuando me imagino Deuda Funcional, esa no es la definición que tengo en mente. De la manera que lo veo, es que para poder hacer una entrega a tiempo, la funcionalidad se implementa parcialmente. La funcionalidad en sí sufre debido a los recortes. Imaginemos que la funcionalidad que hemos de entregar es un simple formulario con campos para imput de ficheros. A medida que nos acercamos más al tiempo de entrega y no queremos introducir una Deuda Técnica, decidimos simplificar la funcionalidad. Eliminamos el arrastrar y soltar de los documentos adjuntos, soporte de múltiples ficheros, y la verificación de campos sobre la legitimidad de la información.
Nuestra aplicación funciona perfectamente bien, el código es limpio (las partes presentes no necesitan mejoras), y se ha entregado a tiempo. Es un milagro! Bueno, en realidad no. Haciéndolo así, permitimos almacenar información no válida en nuestra base de datos y el “user experience” no es lo suficientemente bueno. Nuestro código es inmaculado y hace exactamente la función que nosotros queremos. No tenemos deuda técnica, sino deuda funcional.
Más tarde, tendremos que volver a esta forma, añadir nuevas partes, integrar un servicio válido y cambiar la UI. A medida que el tiempo transcurre, los desarrolladores no se harán cargo de lo que falta. Les hará falta tiempo para estudiar lo que falta, y tendrán que lidiar con la información tóxica que dejamos pasar en nuestra base de datos. El tiempo invertido en ello es mayor al necesitado en primer lugar para tener una funcionalidad completa. Es el coste que pagamos, el interés de nuestra deuda. Sus efectos son menos dañinos que los de la deuda Técnica, aun así se necesita echar un ojo y cuidar de ellos.
El desarrollador que expone situaciones como la descrita anteriormente es normalmente visto como enemigo de la productividad. Ya que pide tiempo para trabajar en algo que ya funciona. Existen beneficios en parar por un momento y pensar en la deuda funcional que podemos estar adquiriendo, ya que nos puede ahorrar más de un dolor de cabeza en el futuro.
Si este artículo te gustó, te puede interesar:
Principio de responsabilidad única
Sobre Dioses y procrastinación
Arquitectura de microservicios
Simular respuestas del servidor con Nodejs
Suscríbete a nuestro newsletter para estar al día de los eventos, meet ups y demás artículos!
