Superando el Malentendido Fundamental Sobre la Deuda Técnica

Hola, soy JB Rainsberger. Y si deseas ponerte en contacto conmigo para hacer una pregunta después de esta charla, aquí hay algunas formas en que puedes encontrarme. Superando el malentendido fundamental sobre la deuda técnica. Lo que probablemente aprendiste sobre la deuda técnica antes es que hay un montón de trabajo que deberíamos hacer ahora, pero que vamos a hacer más tarde. Porque no podemos hacerlo ahora, pero esperamos poder hacerlo más tarde. Prometo que lo haremos más tarde. Pero debido a que lo vamos a hacer más tarde, en realidad va a costar más hacerlo más tarde de lo que costaría hacerlo ahora. Y cuanto más esperemos, más va a costar. Y todo esto se puede entender como si estuviéramos pidiendo prestado contra nuestra capacidad futura de entregar características y cuanto más esperemos para hacer ese trabajo, más se va a acumular el interés sobre esa deuda hasta que lleguemos al punto en que el interés sea tan alto que ahora estamos entrando en discusiones sobre si hacer ahora el trabajo que pospusimos antes o hacer cosas nuevas que nos has pedido que hagamos ahora. Y es por eso que no podemos entregar tu característica ahora mismo.

Intenté hace aproximadamente una década dar la voz de alarma sobre la relación entre permitir que la complicación aumente en el código y nuestra incapacidad para prever el costo de futuras características. Pensé que iba a resolver el problema para siempre, pero por supuesto no lo hice. Resulta que la arrogancia moralista en realidad no cambia el comportamiento de las personas, incluso si tienes un truco ingenioso y haces una actuación dramática. Así que me gustaría intentar hacerlo mejor esta vez.

¿Qué tipo de deuda técnica es tu deuda técnica? Diferentes personas tienen ideas muy diferentes sobre lo que significa la deuda técnica. La metáfora realmente ha evolucionado en la forma en que la gente piensa sobre ella. Ha habido mucha divergencia entre las personas. Algunas personas lo piensan como algo tan simple como, bueno, no sabemos nada mejor y vamos a aprender y va a ser mejor más tarde, y es por eso que el diseño no es tan bueno ahora como esperábamos que fuera.

Y algunas personas incluso están genuinamente subinvirtiendo en el diseño ahora porque hay alguna necesidad comercial a corto plazo a la que tienen que llegar. Necesito correr ahora y averiguaremos cómo correr el maratón más tarde.

Y no estoy aquí para decirte que la forma en que piensas sobre la deuda técnica es incorrecta, per se, pero tienes que admitir, el hecho de que no estemos de acuerdo sobre lo que significa la deuda técnica lleva a muchos desacuerdos sobre las prioridades de gestión de la deuda técnica y eso lleva a un montón de disfunciones. De hecho, parte de esa disfunción es como los programadores gritando a los gerentes por no darles los recursos que necesitan para hacer su trabajo, o los gerentes gritando a los programadores por no tomar los plazos lo suficientemente en serio, o incluso los programadores gritándose entre ellos, diciéndoles que dejen de sobre-ingeniería cuando, en algunos casos, muchos diría yo, las personas acusadas de sobre-ingeniería simplemente están tratando de tomar en serio la deuda técnica como un problema. Si continuamos así, creo que solo vamos a seguir afianzando la opinión personal de cada uno sobre cuál es la cantidad correcta de esfuerzo que se debe poner en un buen diseño.

Tienes personas de un lado que piensan que necesitamos diseñar más cuidadosamente, refactorizar más a menudo, y señalan el interés acumulado sobre la deuda para justificar su posición. Mientras que tienes a un montón de otras personas que están pidiendo a los programadores que diseñen menos cuidadosamente, que refactoricen menos, que lo hagan en menos tiempo, y señalando afirmaciones vagas sobre, ya sabes, la deuda de otras personas es mala deuda, nuestra deuda es buena deuda, está bien, solo sigue adelante y entrega características. Parece que esta metáfora de la deuda técnica casi nos está fallando, pero no creo que lo sea. Quiero decir, alguien inventó esta metáfora para resolver un problema real. Debería ayudarnos. Tal vez si volvemos a lo que estaban pensando, entonces tal vez haya una pista allí en alguna parte.

Así que volvamos a Ward Cunningham, quien acuñó la frase deuda técnica hace unos 25 años, y en menos de 10 años, ya estaba viendo a la gente realmente luchando y sufriendo tratando de hablar sobre la deuda técnica en sus proyectos. Así que grabó un video corto en el que intentó aclarar sus intenciones y su pensamiento, con la esperanza de que pudiera ayudar. Y así, por ejemplo, sabiendo que estaban trabajando con tecnología con la que no estaban muy familiarizados, asumieron que iban a hacer las cosas mal. Y así, como él lo expresó, era importante para mí que acumuláramos los aprendizajes que hicimos sobre la aplicación a lo largo del tiempo modificando el programa para que pareciera que sabíamos lo que estábamos haciendo todo el tiempo. Este es realmente el poder del diseño evolutivo, la libertad de cambiar el código para que coincida con lo que entendemos ahora y no ser prisioneros de decisiones pasadas porque tuvimos que tomar esas decisiones cuando sabíamos menos.

Y mucha gente tenía esta idea de que usamos esta metáfora de deuda como una forma de explicar a los no programadores por qué los programadores necesitan más tiempo para diseñar o refactorizar. Pero eso no es lo que Ward estaba haciendo. Él estaba tratando de explicar a su jefe, un gerente de desarrollo de software, por qué querían tomarse este tiempo para mantener el diseño del programa alineado con su comprensión emergente del sistema. Y eligió una metáfora financiera porque estaban trabajando en software financiero. Y pensó que esta idea de que si no mantenemos el diseño actualizado con nuestra comprensión emergente íbamos a tropezar continuamente con la brecha entre lo que el código decía y cómo estábamos pensando, que eso continuaría ralentizándonos, que eso empeoraría con el tiempo, y eso es un poco como tener que pagar intereses sobre un préstamo. Y así podría haber elegido fácilmente la metáfora de un dominio diferente, pero eligió una metáfora financiera porque estaban trabajando en el dominio financiero.

Y en ese momento, muchos bloggers, escritores, consultores, y me incluyo en ese grupo, se confundieron, y pensaron en la deuda técnica como una explicación de por qué podíamos salirnos con la nuestra escribiendo código de manera deficiente ahora con la intención de hacer un mejor trabajo en el futuro y explicarlo como deuda. Como lo expresó Ward, nunca estoy a favor de escribir código de manera deficiente, pero sí estoy a favor de escribir código para reflejar tu comprensión actual de un problema, incluso si esa comprensión es parcial. Así que ese era el tipo de deuda técnica de Ward. Una metáfora financiera para personas que trabajan en el dominio financiero para tratar de explicar esta estrategia de gestión de riesgos a un gerente de ingeniería de software, no a una persona no técnica.

Y una indicación no de una técnica deficiente, sino del riesgo continuo de un desajuste entre lo que los programadores entienden y lo que el código dice. No se trata de tratar de explicar por qué estamos escribiendo código de manera deficiente ahora con la intención de escribirlo mejor más tarde. Y así creo que esa es la mala interpretación fundamental sobre la deuda técnica. Que la deuda técnica es el resultado de decisiones pobres o equivocadas por parte de los programadores. Tal vez están bajo presión. Tal vez simplemente no tienen suficiente experiencia. Tal vez simplemente no les importa lo suficiente. Y el costo de esas malas decisiones se acumula con el tiempo y se compone como intereses sobre una deuda impaga. Y por lo tanto, la deuda técnica es un problema para que los programadores lo resuelvan, y si no lo resuelven, entonces están siendo irresponsables con el presupuesto del proyecto o un problema para que el negocio lo resuelva porque necesitan respetar a los programadores lo suficiente para darles amplios recursos para ejecutar sus planes maestros.

Bueno, si esto es un malentendido sobre la deuda técnica, entonces ¿cómo la entendemos mejor juntos? Volvamos a las palabras de Ward, nunca estoy a favor de escribir código de manera deficiente, pero sí estoy a favor de escribir código para reflejar tu comprensión actual de un problema, incluso si esa comprensión es parcial. Ahora, escribir código cuando tu comprensión es parcial parece extraño, pero eso es lo que hacemos todo el tiempo. ¿Quién aquí tiene la oportunidad de trabajar en proyectos donde entiendes el problema perfectamente y cómo diseñar una solución perfectamente antes de escribir cualquier código? Simplemente no hacemos eso.

Y solo se ha vuelto más raro con el tiempo a medida que entregamos características a internet cada día. El mero hecho de que estamos entregando características de manera incremental significa que siempre estamos aceptando el riesgo de escribir código con una comprensión parcial del problema. Siempre este problema no desaparece. Y gestionamos la deuda técnica, obviamente, invirtiendo tiempo y esfuerzo en realinear la base de código con nuestra comprensión emergente del problema. Aprendemos algo, ponemos ese aprendizaje en el código, aprendemos algo, ponemos ese aprendizaje en el código.

Incluso los programadores perfectos trabajando en condiciones ideales encontrarán deuda técnica simplemente al intentar entregar características más pronto. Esto no es una cuestión de personas comportándose mal o no teniendo suficiente habilidad o no teniendo suficiente tiempo. Incluso si las condiciones fueran perfectas, la deuda técnica aún sería un gran problema. Siempre está aquí. No es una cuestión de mala técnica, mala habilidad, malas intenciones, no preocuparse. No es su problema, sin importar quiénes sean o sean. La deuda técnica es un riesgo continuo que necesitamos gestionar juntos.

Y la buena noticia es que gestionar la deuda técnica no requiere técnicas especializadas ni herramientas especializadas. No requiere una vasta experiencia. Pero todas estas interpretaciones distorsionadas de la deuda técnica y lo que significa tenerla y quién es responsable de ella y cuánto necesitamos invertir en saldarla, todo esto lleva a los tipos de comportamientos disfuncionales que nos dificultan ver lo que está justo frente a nuestros ojos. Ahora, la buena noticia es que puedes hacerlo. Puedes renunciar a estos juicios morales sobre el profesionalismo o preocuparte por los resultados y reconocer la deuda técnica como un riesgo continuo que necesitamos enfrentar juntos. Y no pensar en la deuda técnica como algo inevitable, por lo tanto, no hay sentido en hacer algo al respecto, sino como algo que necesitamos cuidar juntos y ser vigilantes juntos.

Que no hay todo o nada cuando se trata de deuda técnica, al igual que no hay todo o nada cuando se trata de defectos. Los defectos son inevitables porque cometemos errores, pero eso no significa que no lo intentemos. Y podemos adoptar la misma actitud en lo que respecta a la deuda técnica. De hecho, si hay una parte de la metáfora de la deuda que podríamos realmente utilizar, y esa es que endeudarse lleva tiempo, tiende a suceder gradualmente a pesar de nuestros mejores esfuerzos. Y por lo tanto, mientras el aforismo dice que si endeudarse lleva tiempo, entonces salir de la deuda lleva tiempo, no podemos esperar que sea un problema que se resolverá esta noche.

Ahora, eso es una buena noticia. Una mala noticia es que tienes que hacerlo. No puedes esperar salir de ello. No puedes desear salir de ello. No puedes leer para salir de ello. El trabajo implica rediseñar el código continuamente a lo largo de la vida del proyecto o del producto para alinearlo con nuestra comprensión emergente del problema y cómo resolverlo. Requiere vigilancia y determinación, y esas cosas son aburridas. Es muy fácil perder el interés, perder la motivación y detenerse. Y la única cosa, tal vez la única cosa peor que gestionar la deuda técnica es no gestionarla Es como ser un árbitro en el béisbol. La única vez que hablan de ti es cuando no estás haciendo tu trabajo. Pero la buena noticia es que hay ciclos virtuosos aquí. Cuanto más tiempo pases, más esfuerzo dediques a cultivar el diseño, más fácil se vuelve.

Mejoras en ello, y se siente más fácil. Y cuanto más cambias tus elecciones pasadas para alinearlas con tu comprensión actual, menos arrepentimiento tendrás sobre las elecciones futuras. La base de código mejora con el tiempo. Cuando haces que realinear el código con tu comprensión emergente del problema y cómo resolverlo, cuando haces de eso una parte ordinaria del trabajo, sientes menos resistencia a hacerlo cuando necesitas hacerlo. Así que cuando llegas al momento de necesitar hacerlo, es más probable que lo hagas. El momento clave es cuando lees el código, te sientes confundido, tienes el momento de aha.

Ese es el momento en el que estás haciendo la arqueología necesaria para reingeniería inversa del conocimiento perdido. Y ese es el momento en el que tu comportamiento es crítico. Cuando cambias el código para reflejar más de tu comprensión emergente del problema a medida que avanzas, ese es el movimiento que más importa. Y simplemente tienes que hacerlo. Hazlo tan bien como puedas, de cualquier manera que puedas, tanto como puedas durante el tiempo que puedas.

Y no te preocupes por el hecho de que nunca estarás satisfecho con cuánto de ello haces. Nunca estarás satisfecho con lo bien que lo haces. Pero hacerlo ayuda más que no hacerlo. Y no importa cómo lo hagas, siempre y cuando lo hagas. No importa qué técnicas uses, qué trucos uses, cómo pienses sobre ello, siempre y cuando en ese momento clave, tomes tu comprensión emergente de cómo el código debería ser diseñado y pongas esa información de nuevo en el código.

Pero soy Jay Brains, así que tengo que hablar sobre el desarrollo guiado por pruebas. Y sí, TDD es útil aquí porque hace que la gestión de la deuda técnica sea una parte ordinaria de la programación. El paso de refactorización del desarrollo guiado por pruebas nos condiciona a pensar en mejorar el diseño del código existente como algo ordinario que hacemos todos los días, en lugar de algo que necesita estar en un plan o alguna cosa opcional sobre la que podemos discutir en una reunión de planificación. Simplemente hace que esa parte de la programación sea algo que hacemos con muy poca fanfarria, y simplemente seguimos haciéndolo con el tiempo y los beneficios se acumulan con el tiempo. Para mí, el verdadero poder del desarrollo guiado por pruebas no está meramente en tener pruebas que nos permitan escribir código que se comporte correctamente, o que haga que la refactorización sea más segura, sino en construir hábitos que tomen en serio la deuda técnica como un riesgo continuo inherente a la entrega de características en el mundo de hoy.

No es lo único que puedes usar. El pensamiento técnico, incluso lo más básico, el tipo de cosas que aprendes en un libro como Grocking Simplicity, que me gusta mucho, estas pueden ayudar mucho con la gestión de la deuda técnica. Inmutabilidad, transparencia referencial, aislar cálculos de acciones, estas no son cosas que repagan la deuda técnica por sí solas, pero al hacer que el código sea más fácil de entender y cambiar con confianza solo con leerlo. Esto reduce la resistencia a cambiar el código cuando llegas a ese momento clave y verás una brecha entre lo que dice el código y cómo piensas sobre el problema.

Y reducir esa resistencia hace que sea más probable que tomes los pocos momentos que necesitas para realmente llevar el código, para realinear el código con tu comprensión emergente del problema y cómo resolverlo. Pero no tienes que hacerlo a mi manera. Lo que más importa es tu intención y aún más tu comportamiento en ese momento clave cuando estás reingeniería inversa del conocimiento perdido. Cualquier pensamiento, hábito, truco, técnica, mentalidad, filosofía, que haga más probable que puedas poner ese conocimiento de nuevo en el código en lugar de dejar que se deteriore de tu mente es uno que puedo apoyar.

No importa cómo lo hagas mientras lo hagas, lo que significa que puedes hacerlo de la manera que realmente lo harás siempre y cuando sigas haciéndolo. Incluso cuando es aburrido, incluso cuando parece que no importa, incluso cuando nadie lo agradece. Sé que no es increíble, pero lo único peor que hacerlo es no hacerlo.

Las frías verdades sobre la deuda técnica son estas. El mero hecho de intentar entregar características de manera incremental significa aceptar el riesgo de deuda técnica, no importa cuán excelente seas en tu trabajo, no importa qué tan bien vayan las cosas, no importa cuán armonioso sea el contexto. Una deuda técnica sin restricciones significa que eventualmente todo se detiene y nunca lo verás venir. Quiero decir, sabrás que viene, pero no podrás verlo venir.

Y la mejor apuesta que puedes hacer en ese momento es si por casualidad saltas del proyecto antes de chocar contra la pared de ladrillos. La deuda técnica no es nuestro problema. No es su problema. Es un riesgo compartido que necesitamos gestionar juntos. Y todos estarán en desacuerdo sobre la cantidad correcta de inversión en diseño, en refactorización, en pagar la deuda técnica. Nunca... Esta no es una ecuación que podamos hacer. No podemos poner números en una hoja de cálculo y resolverlo.

Esto es algo sobre lo que siempre estaremos discutiendo, para siempre. Y la única vez que podemos ignorar con seguridad la deuda técnica es cuando el proyecto realmente no importa. Y tengo que admitir, he trabajado en algunos de esos. Ahora, en ese contexto, hay estrategias obvias que ayudan. Tratar la deuda técnica como un riesgo compartido continuo a gestionar por toda la comunidad del proyecto y no pensar en ello como un problema que ellos, quienquiera que sean, necesitan resolver.

Necesitamos reservar una parte del presupuesto para mantener periódicamente el código alineado con nuestro entendimiento colectivo emergente del sistema. No podemos evitarlo. Necesitamos tratar el pago de la deuda técnica como un experimento continuo donde convergemos hacia un equilibrio entre producir características ahora y producir características en el futuro. Nunca vamos a descubrir la cantidad correcta de pago a realizar. Solo tenemos que seguir adelante.

Y ese cliente impaciente o propietario del producto o gerente de producto, como sea que los llames en tu organización, la persona que está presionando a los programadores para refactorizar menos y enviar características más pronto, esa persona no es un obstáculo. Esa persona, bueno, lo son, pero esa persona es una señal de que tu proyecto realmente significa algo para alguien. Si esa persona no estuviera allí, nada de esto importaría. Y así, esa persona que presiona a los programadores para ir más rápido, lo que sienten presión para hacer, por eso está sucediendo. No son una excusa para simplemente ceder y hacer lo que quieran.

Es una razón para tomar la gestión de la deuda técnica aún más en serio en este proyecto. Vuelve al comentario de Ward de que, debido a que conocía los riesgos que estaba asumiendo, era importante gestionar la deuda técnica de manera efectiva. Ahora, algunos de ustedes, por supuesto, se darán cuenta o me dirán que no puedo hacer estas cosas debido a esa persona o esa política. Y sí, lo entiendo. Puedes llenar una librería con trucos y estrategias para sortear estos problemas. Las situaciones son complejas y no hay soluciones rápidas.

Es realmente arriesgado ofrecer consejos genéricos y ni siquiera lo voy a intentar. Si quieres hacerme preguntas más tarde, podemos hablar sobre tu contexto y tomarnos todo el tiempo que necesitemos para hablar de ello sensatamente. Pero simplemente tratar de darte consejos genéricos que podrían o no funcionar es en realidad peor porque estas son situaciones complejas que debes manejar con delicadeza. Y esto es un aprendizaje continuo de por vida. Esto es lo que significa convertirse en un líder técnico. Entonces, ¿hay algún optimismo aquí? Bueno, depende de lo que consideres optimista.

Quiero decir, la mayoría de las personas son bastante malas gestionando la deuda técnica, así que el listón está bajo. Gran parte del conflicto relacionado con la deuda técnica proviene de suposiciones extrañas que hacemos y que podemos decidir no hacer. Podemos dejar ir esas cosas. Tienes que dar el primer paso. Y gestionar la deuda técnica es realmente solo hacer cosas que ya sabes cómo hacer pero tratando de descubrir cómo eliminar los obstáculos para realmente hacerlas. Y nunca eliminarás la deuda técnica, así que no hay un final al que intentar llegar.

De hecho, mientras sigas adelante, mientras estés tratando de reducir la deuda técnica con el tiempo, lo estás haciendo bien. Encuentro eso bastante optimista. Quizás empieza aquí. Lee algunos artículos. Eso no cuesta nada. Hazme una pregunta. Siempre que estés dispuesto a esperar para siempre por la respuesta, ese servicio es gratuito. Y si necesitas ayuda, si necesitas un mejor acuerdo de nivel de servicio, si necesitas mi atención, hay horas de oficina. Hay formas en que puedes trabajar con personas como yo para ayudarte a entender cómo convertirte en el líder técnico que tu organización necesita para gestionar la deuda técnica de manera efectiva. Hagas lo que hagas, buena suerte. Es difícil ahí fuera. Solo sigue adelante. Paz.