Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados

Rate this content
Bookmark

Casi nadie en el mundo de la tecnología disfruta cuando hay mucha deuda técnica. Y a la mayoría de nosotros nos gustaría que no haya demasiada. Pero, ¿cómo entendemos cuánta tenemos exactamente? ¿Dónde se encuentra exactamente? ¿Qué parte de ella es realmente la más molesta? ¿Cuál sería el beneficio para nosotros si dedicamos tiempo a deshacernos de ella? Cuando se trata de planificar cómo abordar tu deuda técnica, todas estas preguntas merecen respuestas. Especialmente cuando nos preguntan sobre el retorno de la inversión en nuestros esfuerzos para eliminar cosas antiguas molestas y construir un nuevo módulo o servicio brillante. Además, cuando trabajamos en la deuda técnica, queremos abordar primero las partes más impactantes, ¿verdad? Esta charla trata sobre todo eso: cómo medimos nuestra deuda técnica, cómo interpretamos los resultados de estas mediciones para que nos den las respuestas a las preguntas correctas, y cómo guiamos nuestra toma de decisiones con esas respuestas.

This talk has been presented at TechLead Conference 2023, check out the latest edition of this Tech Conference.

FAQ

La deuda técnica, según Ward Cunningham, es una herramienta que permite acelerar el desarrollo de software temporalmente al tomar atajos, lo que acelera los procesos a expensas de posibles ralentizaciones futuras.

La deuda técnica se vuelve realmente mala en dos escenarios: la deuda técnica continua es inmediatamente mala al implementarse en producción, mientras que la deuda técnica de mantenimiento se vuelve problemática cuando es necesario introducir cambios en las áreas afectadas.

Las métricas heurísticas de deuda técnica son medidas automatizadas que evalúan aspectos como la complejidad del código, la duplicación de código y los malos olores de código, entre otros. Estas métricas son útiles para obtener una visión general de la salud de la base de código.

El interés de la deuda técnica es crucial porque permite medir el impacto real de la deuda técnica en los esfuerzos de desarrollo, ayudando a identificar el costo adicional en tiempo y recursos que impone la deuda técnica en cada ticket o tarea.

Las métricas de segundo nivel, como el tiempo de ciclo de los tickets y las tendencias de errores, ayudan a monitorear la salud del software y la eficiencia del equipo, proporcionando información clave para priorizar la resolución de la deuda técnica basada en su impacto comercial.

Entre las herramientas mencionadas para la medición de deuda técnica están SonarQube y Code Climate Quality, que ofrecen análisis automatizados y métricas heurísticas relevantes para evaluar la calidad del código.

Anton es el director de ingeniería en Westing, Alemania, y en TechLeadConf, compartió su experiencia y conocimientos sobre la medición del liderazgo técnico y la interpretación de resultados relacionados con la deuda técnica.

Para determinar si un fragmento de software tiene deuda técnica, se evalúan aspectos como la facilidad de análisis y entendimiento, la facilidad y seguridad de modificación, y si cumple con requisitos técnicos como la escalabilidad y la seguridad.

Anton Kazakov
Anton Kazakov
27 min
09 Mar, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute la medición e interpretación del liderazgo técnico, centrándose en la deuda técnica. La deuda técnica es una herramienta para acelerar temporalmente el desarrollo, pero puede tener consecuencias negativas si no se gestiona adecuadamente. Varios indicadores de deuda técnica, incluidos los indicadores heurísticos y los indicadores de segundo nivel, pueden ayudar a identificar y gestionar la deuda técnica. El interés de la deuda técnica es crucial para medir el impacto de la deuda técnica y permite la priorización. Es importante recopilar y analizar los indicadores de deuda técnica para garantizar la salud del software y del equipo.

1. Introducción

Short description:

Hola a todos. Mi nombre es Anton, y gracias por recibirme en TechLeadConf este año. En los próximos 20, tal vez 25 minutos, hablaré sobre la medición del liderazgo técnico e interpretación de los resultados. Espero que esta charla les sea útil e interesante. Lidero organizaciones de ingeniería y mentoro a otros líderes de ingeniería. No duden en contactarme para mentoría o coaching. Comencemos de inmediato.

Hola a todos. Mi nombre es Anton, y gracias por recibirme en TechLeadConf este año. En los próximos 20, tal vez 25 minutos, hablaré sobre la medición del liderazgo técnico e interpretación de los resultados. Espero que esta charla les sea útil e interesante.

Algunos detalles sobre mí, lidero organizaciones de ingeniería. Actualmente soy director de ingeniería en Westing en Alemania. También mentoro y doy coaching a otros líderes de ingeniería, como gerentes de ingeniería y principales ingenieros. Si estás buscando un mentor o un coach, no dudes en contactarme, siempre estoy disponible. También fuera del trabajo, soy padre y un gran fanático del esquí de montaña y el senderismo, entre otras cosas. A continuación, puedes ver mi nombre de usuario de Twitter y mi información de contacto, como mi dirección de correo electrónico y también el enlace para conectarte conmigo en LinkedIn. Y sí, con eso, comencemos de inmediato.

2. Understanding Tech Debt

Short description:

La deuda técnica no es inherentemente mala, pero depende de varios factores. Es una herramienta para acelerar temporalmente el desarrollo al tomar atajos, al igual que tomar un préstamo. Para determinar si tenemos deuda técnica, podemos analizar nuestro software y responder preguntas como facilidad de análisis, modificación y seguridad. Hay dos tipos de deuda técnica: deuda técnica de mantenimiento, que ralentiza los cambios debido a un diseño imperfecto, y deuda técnica continua, que requiere tiempo para mantener la aplicación operativa. La deuda técnica continua se vuelve problemática cuando se implementa en producción, lo que provoca errores, tiempo de inactividad, violaciones de seguridad y pérdida de ingresos. Por lo tanto, es importante gestionar la deuda técnica para evitar consecuencias negativas.

Comencemos con una sorpresa. ¿Qué les parecería si les dijera? Como dice nuestro querido amigo Morpheus, que no toda su deuda técnica realmente necesita ser resuelta. Apoyo completamente esta afirmación, en realidad, esta pregunta en particular. Y para entender cómo es que no toda la deuda técnica necesita ser resuelta y también cómo contradice una creencia relativamente popular de que la deuda técnica es generalmente la raíz de todo mal, veamos algunas cosas.

Entonces, empecemos por ¿qué es la deuda técnica? Si no es la raíz de todo mal. Fue el término acuñado por este tipo, Ward Cunningham, en 1992. Y él era mucho más joven en ese momento, porque esta es una captura de pantalla de su video explicativo en YouTube que publicó en 2009. Y el video se llama Metáfora de la Deuda Técnica. Y él habla en profundidad sobre esto. Aquí hay un par de citas, que no vamos a leer. Simplemente las pasaremos por alto. Entonces, según Ward Cunningham, el autor del término deuda técnica, no es la raíz de todo mal. Y lo que es, es una herramienta para acelerar temporalmente el desarrollo al elegir tomar atajos para acelerar ahora a expensas de ralentizar después. Al igual que tomar un préstamo, podemos permitirnos algo antes de ganarlo por completo, y luego tenemos que pagar intereses. Entonces, dado que es una herramienta, ¿la deuda técnica es inherentemente mala? Bueno, preguntémosle a nuestro querido amigo Morpheus y él nos dirá que la respuesta correcta es depende. Como muchas preguntas en el ámbito de la ingeniería de software, ¿en qué depende? Esa es la parte interesante, ¿verdad? ¿En qué depende, cómo podemos ver en qué depende? Bueno, primero, veamos cómo determinamos si tenemos deuda técnica en primer lugar. Eso lo podemos hacer al observar nuestro software y responder a una serie de preguntas. Primero, ¿es fácil de analizar y entender? Este fragmento de software. Segundo, ¿es fácil de modificar? Tercero, ¿es seguro modificarlo? Y finalmente, la cuarta pregunta, ¿hay algún requisito técnico necesario, por ejemplo, escalabilidad, estabilidad, requisitos de seguridad que no se han implementado? Y si respondemos sí a alguna de estas preguntas, tenemos deuda técnica en este fragmento de software.

Además, lo que me gusta distinguir son dos tipos de deuda técnica. El primero es la deuda técnica de mantenimiento. Esta es la deuda técnica relacionada con las primeras tres preguntas, que básicamente es la parte de la deuda técnica que ralentiza nuestros cambios, ya sean características o cualquier otro tipo de cambios en nuestra base de código. Simplemente los implementamos más lentamente debido a la deuda técnica, porque el diseño no es perfecto. Y la segunda parte de la deuda técnica es la deuda técnica continua. Lo que significa que necesitamos dedicar tiempo, debido a alguna deuda técnica en nuestra aplicación, a mantener la aplicación operativa. Y esta deuda técnica reduce el tiempo que podemos dedicar a introducir cambios en nuestra base de código. Así es como estos dos tipos de deuda técnica son diferentes, y así es como definen de manera diferente la respuesta a la pregunta, ¿cuándo se vuelve realmente mala la deuda técnica? Porque no toda es inherentemente mala, pero ¿cuándo se vuelve mala? Bueno, la deuda técnica continua es inmediatamente mala tan pronto como la implementamos en producción. Entonces, cualquier atajo, ya sea en confiabilidad, escalabilidad, atajos de seguridad, produce algunas consecuencias de primer orden como errores, tiempo de inactividad, violaciones de seguridad, Dios no permita que se roben datos, lo cual a su vez produce esfuerzo ad hoc, cambio de contexto, que como sabemos, es otro gran consumidor de productividad. A veces pérdida de ingresos, a veces cosas peores que eso, como daño reputacional a largo plazo, y así sucesivamente. Así que no queremos eso.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Un Marco para Gestionar la Deuda Técnica
TechLead Conference 2023TechLead Conference 2023
35 min
Un Marco para Gestionar la Deuda Técnica
Top Content
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Principios para Escalar el Desarrollo de Aplicaciones Frontend
React Summit 2023React Summit 2023
26 min
Principios para Escalar el Desarrollo de Aplicaciones Frontend
Top Content
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
Luchando contra la Deuda Técnica con la Refactorización Continua
React Day Berlin 2022React Day Berlin 2022
29 min
Luchando contra la Deuda Técnica con la Refactorización Continua
Top Content
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
IA y Desarrollo Web: ¿Exageración o Realidad?
JSNation 2023JSNation 2023
24 min
IA y Desarrollo Web: ¿Exageración o Realidad?
Top Content
This talk explores the use of AI in web development, including tools like GitHub Copilot and Fig for CLI commands. AI can generate boilerplate code, provide context-aware solutions, and generate dummy data. It can also assist with CSS selectors and regexes, and be integrated into applications. AI is used to enhance the podcast experience by transcribing episodes and providing JSON data. The talk also discusses formatting AI output, crafting requests, and analyzing embeddings for similarity.
Construyendo equipos interculturales de alto rendimiento
React Day Berlin 2022React Day Berlin 2022
25 min
Construyendo equipos interculturales de alto rendimiento
The Talk discusses the importance of effective communication and collaboration in cross-cultural teams. It emphasizes the impact of culture on communication and performance evaluation. The speaker highlights the differences between low-context and high-context communication styles and the need to understand cultural nuances. It also explores the challenges of giving feedback in multicultural teams and suggests ways to improve communication and create a feedback culture. The influence of language on communication and the importance of transparency and honesty in feedback are also discussed.
Olvida el mal código, concéntrate en el sistema
React Summit US 2023React Summit US 2023
27 min
Olvida el mal código, concéntrate en el sistema
Top Content
Setting up the system and separating concerns are important in software development. Modular construction and prefab units are a new trend that makes construction quicker and easier. Architectural complexity can lead to a drop in productivity and an increase in defects. Measuring architectural complexity can help identify natural modules in the code. Best practices for avoiding architectural complexity include organizing code by business domain and using prop drilling. Atomic design and organizing a monorepo are recommended approaches for managing architectural complexity.

Workshops on related topic

De Ingeniero a Líder: Un Masterclass para Líderes Tecnológicos Primerizos
TechLead Conference 2024TechLead Conference 2024
144 min
De Ingeniero a Líder: Un Masterclass para Líderes Tecnológicos Primerizos
Workshop
Andrew Murphy
Andrew Murphy
Transicionar de un rol de contribuidor individual a una posición de liderazgo, especialmente en la industria tecnológica de ritmo acelerado, es enormemente desafiante. La mayoría de los nuevos líderes no reciben ningún tipo de capacitación en los primeros 10 años de sus nuevas responsabilidades.Nuestro completo masterclass está diseñado para ayudar a los nuevos y emergentes líderes tecnológicos a comprender sus nuevos roles y adquirir las habilidades para convertirse en líderes seguros, felices y efectivos.
Managers Are From Mars, Devs Are From Venus
TechLead Conference 2024TechLead Conference 2024
111 min
Managers Are From Mars, Devs Are From Venus
Workshop
Mo Khazali
Mo Khazali
Una Guía para Desarrolladores sobre Cómo Comunicar, Convencer y Colaborar Efectivamente con los Stakeholders
Es una historia tan antigua como el tiempo: la colaboración entre desarrolladores y stakeholders de negocios ha sido durante mucho tiempo un desafío, con una falta de comunicación clara que a menudo deja a ambas partes frustradas. Los mejores desarrolladores pueden comprender profundamente las necesidades de sus contrapartes de negocios, comunicar efectivamente la estrategia técnica sin perder a la audiencia no técnica y convencer al negocio de tomar las decisiones correctas. Trabajando en una consultoría, he fallado y tenido éxito en arquitectar y “vender” visiones técnicas, aprendiendo muchas lecciones en el camino.Ya sea que trabajes en una empresa de productos, seas consultor/freelancer, o quieras aventurarte más allá de ser solo un desarrollador, la capacidad de convencer y comunicar claramente con los stakeholders puede diferenciarte en la industria tecnológica. Esto se vuelve aún más importante con el auge de GenAI y el mercado de desarrolladores cada vez más competitivo, ya que la resolución de problemas y la comunicación efectiva son clave para posicionarte.En esta masterclass, compartiré ejemplos del mundo real, tanto buenos como malos, y te guiaré a través de poner la teoría en práctica mediante dojos.
Fuera de la sartén, al fuego: Guía para gerentes sobre cómo ayudar a los nuevos desarrolladores a prosperar
TechLead Conference 2024TechLead Conference 2024
35 min
Fuera de la sartén, al fuego: Guía para gerentes sobre cómo ayudar a los nuevos desarrolladores a prosperar
Workshop
Andrew Coleburn
Andrew Coleburn
Integrarse a un nuevo proyecto puede ser difícil, sin importar tu experiencia y antecedentes. Pero puede ser especialmente desafiante para los nuevos desarrolladores recién salidos de la escuela o de un bootcamp de programación. Basándose en su experiencia personal como graduado de un bootcamp y consultor de JavaScript, esta charla discutirá consejos y estrategias para que los gerentes ayuden a los nuevos desarrolladores de sus equipos a familiarizarse con un código desconocido, para que puedan tener un impacto más rápido y efectivo.