El cuadrante de la deuda técnica
- Detalles
- Publicado: Miércoles, 21 Octubre 2009 12:22
- Escrito por Leonardo De Seta
La Deuda Técnica es una excelente metáfora (creada por Ward Cunningham) que nos ayuda a pensar sobre algunos problemas del desarrollo de software. Según la metáfora, hacer las cosas rápido y mal nos incrementa las deuda técnica, la cual es similar a la deuda financiera. Al igual que la deuda financiera, la deuda técnica tiene pago de intereses, que vienen en la forma del esfuerzo extra que será necesario hacer en el futuro por una elección rápida y mala de diseño. Podemos decidir seguir pagando el interés, o podemos pagar el capital al hacer un refactor del diseño hacia un diseño mejor. Aunque hay un costo de pagar este capital, nos ahorramos el pago de intereses en el futuro.
Según un 
Determinar el costo y tiempo de un proyecto de software es uno de los temas más importantes en el desarrollo de software. Mi opinión seguramente va a ser polémica, y acá está: es imposible determinar cuál será el costo y el tiempo de un proyecto de desarrollo de software. Más aún, es muy mala idea intentar usar la planificación como si fuera un contrato con nuestro cliente.
En general nadie crea código inmantenible de forma intencional (ignorando los casos de algunos consultores que escriben mal código para forzar a quedarse con el contrato). Sin embargo, el mal código va creciendo de forma lenta y segura a lo largo del ciclo de vida del producto.
¿Alguna vez se sintieron como malabaritas con el trabajo, haciendo las cosas apurados a contra reloj? Sí, yo también. Trabajar después de hora apesta. Siempre sentí que debido a la mala planificación yo tenía que lidiar con un día eterno, o noche, o fin de semana (y a veces los 3!). Para los equipos ágiles, trabajar después de hora es malo de tantas maneras distintas que se hace dificil enumerarlas.
Como programador, no te va a salir todo bien todo el tiempo, y no siempre vas a entregar a tiempo lo prometido. Quizás subestimaste. Quizás no entendiste los requerimientos. Quizás el framework que elegiste no era el indicado. Quizás supusiste cosas en vez de recolectar datos. Si probás cosas nuevas, hay probabilidad de que falles de vez en cuando. Sin probar, no aprendés. Y sin aprender, no podés ser efectivo.
No hace falta ser Sherlock Holmes para descubrir que los buenos programadores escriben buen código. Y los malos programadores... no. Los malos programadores crean monstruos que el resto de nosotros tiene que limpiar. Querés escribir buen código, ¿no? Querés ser un buen programador.
Sos un programador. Eso signifca que tenés una presión tremenda por trabajar rápido. Hay fechas que cumplir. Hay bugs que arreglar antes de la gran demo. Hay calendarios productivos a los que llegar. Y tu trabajo depende de cuán rápido vayas y qué tan confiable seas para cumplir las planificaciones. Y esto significa que tenés que tomar atajos, compromisos, ser rápido y desprolijo.
Es dificil construir un buen espacio de trabajo para un equipo de desarrollo. Hay que balancear muchos factores: humanos, sociales, ambientales, económicos y personales. No existe una solución universal, pero si podemos compartir algunas lecciones aprendidas durante los años.
Mientras más simple, mejor. Esto es algo que a menudo olvidamos cuando desarrollamos software: nos vemos tentados por usar patrones de diseño, frameworks, tecnologías, herramientas... sin considerar otras opciones más simples aunque menos populares. Si hay dos formas de implementar algo y son funcionalmente equivalentes y no añaden ninguna repetición al sistema, hay que elegir la solución más simple.
Una y otra vez aparece el tema de la documentación, durante y después de los proyectos. ¿Qué documentación deberíamos crear? ¿Por qué necesitamos documentos de diseño? ¿Cómo podemos asegurarnos de estar construyendo el software indicado si no tenemos un Documento de Diseño Funcional? Y si el Documento de Diseño Funcional no está alineado con el software que se está construyendo, ¿cómo podemos comprobar que obtenemos lo que pagamos? Y más...