María Cristina Tamayo Ossa
Jaime Moncada
Roberto Sánchez
¿Qué es la deuda técnica en desarrollo de software?
La deuda técnica es una metáfora utilizada para describir ciertos compromisos que se hacen durante el proceso de desarrollo de software. Al igual que una deuda financiera, puede ser manejable en el corto plazo, pero con el tiempo puede aumentar en complejidad e impacto si no se "paga". Los desarrolladores, en ocasiones, sacrifican calidad por velocidad, lo que genera una acumulación de problemas que eventualmente deben abordarse.
¿Cómo se manifiesta la deuda técnica?
La deuda técnica suele presentarse de manera similar al caos de cables en un escritorio. Aunque las intenciones iniciales sean las mejores para mantener todo organizado, el caos puede reaparecer debido a varios factores, como cambios frecuentes, mantenimiento o influencias externas. En software, esto se traduce en código desorganizado o sistemas obsoletos, como el uso de lenguajes de programación muy antiguos, que eventualmente pueden llevar a fallos significativos en sistemas críticos.
Ejemplos significativos de deuda técnica
Sistemas obsoletos: Un caso notable fue el sistema de desempleo del estado de New Jersey durante la pandemia de COVID-19. Utilizaba COBOL, un lenguaje de programación de los años 60, lo que resultó en la necesidad urgente de programadores para parchear el sistema.
Interacciones rápidas sin planificación adecuada: Cuando se construye un sistema rápidamente, errores no planeados, como bugs, pueden interrumpir el funcionamiento. Esto es similar a construir un túnel rápido sin considerar filtraciones que podrían ser perjudiciales.
Errores visuales y de interfaz: La aplicación móvil de Platzi, aún con intenciones de iteración rápida, mostró errores de idioma en su interfaz debido a strings no posicionados correctamente, lo cual representa una inequívoca deuda técnica.
¿Cuándo la deuda técnica se convierte en un problema grave?
La deuda técnica se convierte en un problema cuando interfiere con el desarrollo o la eficiencia del producto. Permitir que esta deuda se acumule sin un plan claro para resolverla puede llevar a consecuencias serias. Algunos puntos a considerar incluyen:
¿Cómo manejar la deuda técnica eficazmente?
Para evitar que la deuda técnica se convierta en un impedimento significativo es esencial encontrar un balance entre rapidez de iteración y calidad del producto final. Algunas estrategias para manejarlas incluyen:
En el mundo del software, mantener un equilibrio entre iterar rápidamente y administrar la deuda técnica es clave para el éxito y la sostenibilidad a largo plazo del producto.
María Cristina Tamayo Ossa
Jaime Moncada
Roberto Sánchez
Ranse Rivas
Carlos Morales
Diego Perdomo
Richard Rodas
Andrés Soret Chacin
Guillermo Alomia Monjaraz
Jorge Alejandro Falcon Alvarez
ProfesorPlatzi Team
Nicole Chapaval
ProfesorIgnacio Eduardo Muñoz Damanes
Andrés Soret Chacin
Dario Alejandro Garcia Linares
Andrés Soret Chacin
Fabio Emilio Buiza Lopez
María Cristina Tamayo Ossa
Diego Perdomo
Usuario anónimo
UserPEDRO CASTRO RODRIGUEZ
Ivan David Escobar Rossi
Camilo Arias Céspedes
Brayan Stiven Castaño Zuluaga
Sebastian Restrepo Ortiz
Sergio Rubiano
Juan Álvaro Sánchez Vázquez
Cinthya Alejandra Villegas Reyes
Roberto Sánchez
José Mauricio Osorio Corredor
Joyce Gregory Duque Zabala
Deuda técnica mala = deuda que hacia futuro pueden aniquilar el negocio.
Preguntar al equipo de ingeniería: "Esto que quieren cambiar ¿Afecta a los usuarios? - Si o No? Si no afecta los usuarios o si no hay cambio positivo, muy probablemente los ingenieros están pagando deuda técnica. Los equipos de ingeniería aman optimizar y en ocasiones lo hacen probando cosas nuevas. Esto significa, que muchas veces van a tratar de venderte una mejor que realmente no afecta a los usuarios para nada; pero utilizan adjetivos que no significan nada: robusto, veloz, ágil.
Hacer las preguntas clave: Si nosotros no arreglamos esto, ¿en cuánto se va a volver un problema? Es importante mantener tracking de la deuda técnica, mantener un registro de dónde ocurre?.
La rápida iteración es mejor que tener un producto perfecto (mejora continua = constante iteración).
Es mejor que los usuarios me den feedback rápidamente, incluso cuando algo está roto, es mejor a tener el **producto ideal **que nadie ve nunca y que la luz nunca está ahí.
El código se hace para mover el negocio.
Buen resumen, gracias!
Genial
El mejor ejemplo de deuda técnica está en los vehículos... jejeje...
Buen ejemplo!!
Excelente ejemplo.
Deuda tecnica de Platzi:
TOTAL 👌👌
like
El uso real es mejor que ser perfeccionista, pero no significa olvidar tu deuda técnica, ya qué eventualmente puede convertirse en un stopper total.
La deuda técnica es inevitable y siempre estará ahí, la diferencia está en como la afrontas.
Hoy mi CIO sacó el concepto de que no estamos midiendo la deuda técnica y me lucí porque había llevado el curso :D
Para complementar el tema de la deuda técnica y cuándo hay que resolverla dejo una lectura sobre Cost of Delay que ayuda a tomar decisiones.
Platzi es el ejemplo más claro de que hacer una aplicación es difícil. Aun así cuando ellos mismos enseñan a hacerla.
Sin duda Ignacio. Estoy completamente de acuerdo 👌
La deuda técnica en pocas palabras es causada por la postergación de deberes , se debe de mitigar mediante la rápida iteración
Muy buen aporte. Muchas gracias 😁👍
Me gusta esta explicación. Gracias
Ejemplo del perfil vendedor y/o arrogante: se vuelven peligrosos cuando les apasiona más la tecnología como tal que la solución (quieren volver a hacer todo desde cero, quieren probar las últimas tecnologías aunque no sean las correctas. Sin un análisis profundo.
Es bueno saberlo. El reto mayor reto que veo es en hacer un análisis profundo para determinar qué cambios se hacen a nivel de tecnología. Creo que se necesita mucha práctica y muchos conocimientos técnicos para poderlo dominar.
✨Mantener tracking o seguimiento de la deuda técnica nos permite evitar errores de la aplicación, esto permite minimizar los riesgos.
Hoy me eh dado cuenta que tengo una deuda técnica y que estamos aprovechando la pandemia para realizar los cambios necesarios
Hice una reflexión y resumen de este concepto en un post de LinkedIn, bienvenidos a conectar:
Wooou, interesante lo de la deuda técnica, en el sitio donde trabajaba programé muchas macros en Excel, a medida que se requerian nuevas cosas luchaba para cumplir con los nuevos requerimientos y ajustarlas a lo que ya había creado, me acuerdo que una actualización quedó pendiente. El código de la macro requeriría una actualización después de 9999 registros, cuando ocurra eso no lo sé con exactitud, ahí está la deuda técnica.
a la deuda técnica siempre le abro espacio en cada Sprint. Cuando gestionamos bien los Sprint nos da para programar un Sprint solo de deuda técnica.
Freddy aun tienen muchos bugs, por ejemplo su app no me deja entrar ...
Hola sebas!
Podrías notificar tus problemas de bugs a team@platzi.com de esta manera le darán solución y en el futuro mas estudiantes no tendrás inconvenientes.
Antes de esta clase organice mis cables, me sentí como cuando google te lanza publicidad de un producto después de hablar del mismo unos minutos antes.
Muchas empresas, tristemente están pagando en este momento la deuda técnica de haber desarrollado sobre flash, por no haberse anticipado al cambio tecnológico. 🤦🏻♀️
Deuda Técnica: Cuando tratamos de avanzar muy rápido sin tener en mente los sistemas, estructuras y lógica del negocio. Que nos permite adelantarnos a los problemas que vienen a futuro, para poder construir algo mucho más escalable ...
La deuda tecnica es inevitable, lo importante es hacersen las preguntas claves: Si nosotros no arreglamos esto, ¿en cuánto se va a volver un problema? tambien, es importante mantener tracking de la deuda técnica, mantener un registro de dónde ocurre.
me pasa ese problema con la aplicación de platzi el detalle es que a mi me aparece en portugués y los cursos en portugués