La Deuda Técnica es una metáfora ideada por Ward Cunningham que ayuda a pensar sobre este problema. Viene a decir que en caso de hacer las cosas rápido y de manera chapucera se incurre en una “deuda” que vamos a tener que pagar en el futuro, en forma de esfuerzo de desarrollo, como consecuencia de postergar el buen diseño en la implementación. Y a medida que se siga postergando este esfuerzo y el desarrollo deficiente se siga recubriendo con nuevos desarrollos que lo enmascaren o lo usen, esta deuda será cada vez más elevada y difícil de pagar.
No se quiere decir que no sea sensato incurrir en esta deuda. En ciertas ocasiones es una decisión acertada asumir esta deuda para resolver una situación determinada en un proyecto. Sin embargo, hay que tener en cuenta las repercusiones que puede tomar en el futuro y hay que tratar de satisfacer esta deuda cuanto antes para evitar que crezca desmesuradamente, es decir, que un mal planteamiento en una funcionalidad de la aplicación comprometa la buena marcha del proyecto en el futuro.
Sobre esta idea, Martin Fowler ha desarrollado el “Cuadrante de la Deuda Técnica”. Según él, una deuda técnica asumida en un proyecto puede clasificarse de dos formas:
- Prudente o imprudente.
- Advertida o inadvertida.
La combinación de estas clasificaciones produce cuatro situaciones distintas:
- Deuda prudente y advertida: Se produce cuando somos conscientes de que estamos asumiendo un mal diseño para salir de una situación puntual, como una entrega. Posteriormente se debe evaluar la conveniencia de “pagar la deuda técnica” solucionando esta carencia en función del interés que acarree.
- Deuda prudente e inadvertida: Se produce cuando, con el paso del tiempo, se descubren cómo se deberían haber hecho las cosas. Inevitable, ya que según avanza el proyecto, se aprende de él. Llegado el momento, también se debe evaluar si resulta interesante mejorar el diseño con lo que hemos aprendido o si esto implicaría un esfuerzo demasiado alto.
- Deuda imprudente y advertida: Se deshecha el diseño porque se pretende acelerar el desarrollo. Según la “Hipótesis de Resistencia al Diseño”, esto se puede lograr hasta un punto determinado del proyecto en el que deja de ser posible conseguir un beneficio de obviar el diseño porque la calidad del código se degrada.
- Deuda imprudente e inadvertida: No se conocen las técnicas de diseño ni se es consciente de que se están tomando decisiones incorrectas.
Conviene saber en qué situación nos encontramos. Si bien las tres primeras situaciones se pueden asumir en un momento determinado dentro de un proyecto, la última resulta mucho más peligrosa, porque implica no saber hacia dónde se dirige el proyecto.
Referencias:
La Deuda Técnica
El Cuadrante de la Deuda Técnica
La Hipótesis de Resistencia al Diseño
Buenas Jorge,
ResponderEliminarYa había leido por encima los artículos de Fowler al respecto. La analogía me parece muy acertada.
Respecto a las cuatro situaciones que comentas, en mi triste experiencia:
Deuda prudente y advertida: Sucede siempre y se suele arreglar cuando ya no queda más remedio.
Deuda prudente e inadvertida: Sucede siempre (o debería suceder) o de lo contrario no hemos aprendido nada durante la ejecución de un proyecto. Normalmente se corrige en proyectos sucesivos o cuando el cliente decide "tirar" la solución actual a la basura y volverla a construir.
Deuda imprudente y advertida. Sucede siempre y normalmente suele ser por imposiciones del cliente (interconexión con sistemas legados o simplemente el cliente quiere una nueva funcionalidad que no tiene nada que ver con lo que supuestamente hace la aplicación). Sucede también a veces por que bien o no hay tiempo o no hay dinero. En mi opinión, si no hay tiempo o dinero para hacer algo mejor ni lo intentes.
Deuda imprudente e inadvertida: Sucede siempre y se llama "bug".
En mi opinión siempre deberíamos detenernos y "pagar" esta deuda, en mi triste experiencia rara vez se hace.
Un Saludo
Hola Dirty Affairs y gracias por tu comentario.
ResponderEliminarEn cuanto a las tres primeras situaciones, coincido contigo. Es es la última en la que tengo una idea distinta. En mi opinión no es lo mismo un bug que una chapuza.
Aunque se traten de hacer bien las cosas siempre pueden sugir problemas debido a requisitos que no están muy bien definidos o falta de entendimiento o, simplemente, un error de programación. Si el proyecto se está controlando con pruebas unitarias, de aceptación, etc, no diría que estos bugs que en principio inadvertidos se produzcan de forma imprudente. Más bien los situaría dentro de la deuda prudente e inadvertida, que podemos ir solucionando a medida que evoluciona el proyecto si fuese necesario.
En cambio, si pasamos de todo diseño y de realizar pruebas, ¿cómo descubrimos estos errores? Si no nos molestamos en aprender y en hacer las cosas mejor es cuando caemos en la deuda imprudente e inadvertida, y esto si que no tiene vuelta atrás.