Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Juan (00:00)
Bienvenidos todos a un episodio nuevo de nuestro podcast, tu podcast favorito de tecnología, Dev & Ops. Como siempre, me acompaña aquí mi buen amigo Douglas, quien siempre nos ayuda a ver nuevas perspectivas de todos estos temas que hemos tocado y nos ayuda ⁓ a ver muchos temas que generalmente lo vemos los que somos desarrolladores desde un punto y Douglas nos ayuda a ver otro punto que no hemos visto. Douglas, ¿qué tal? ¿Cómo has estado?
Douglas (00:30)
Juan, ¿qué tal? Muy bien, muy bien, gracias a Dios. Y como siempre digo, contento de estar otra vez en este espacio para poder discutir el tema que tenemos preparado hoy. Con esta introducción que diste, no sé si sentirme bien o sentirme atacado, Juan.
Pero la intención no es tal vez crear controversias, sino más allá generar ese ambiente de colaboración entre la gente de operaciones, los que somos de sistemas y el departamento de desarrollo. Ya que nuestra experiencia trabajando juntos en proyectos reales ha sido muy buena y de mucha colaboración, al final esa es la intención.
compartirle a los demás que es posible esa colaboración ligera, esa colaboración fluida y aprendiendo uno del otro y esa es la intención acá.
Juan (01:24)
Así es, no somos enemigos.
Douglas (01:26)
Así
es.
Juan (01:27)
Y
no, definitivamente es en el buen sentido y más en este tema que tenemos el día de hoy, el cual es la deuda técnica. Este es un tema que, bueno, creo que los que estamos más metidos en el desarrollo tal cual, sin involucrarnos en otros departamentos, pareciera que es un tema meramente de tecnología y meramente del desarrollo de la aplicación. Sin embargo, vamos a ver qué involucra muchas otras cosas.
de hecho en mi opinión Douglas este es un tema que tiene que ver menos con el área técnica o sea con nuestras habilidades técnicas y más con la parte operacional de todo lo que es el equipo de trabajo el el negocio en sí pero bueno vamos a ir explorándolo un poco más vamos a ver un poco más de todo esto no la deuda técnica que creo que todos tenemos experiencia en eso verdad Douglas todos hemos pasado por eso o
o te ha pasado alguna vez donde trabajas y no hay deuda técnica.
Douglas (02:33)
No, tal vez una o dos veces que soñé en un mundo perfecto y cuando desperté ya volví otra vez a deuda técnica. Fuera de ello, no importa en qué lugar esté, ha existido y existirá para siempre la deuda técnica.
Juan (02:43)
a nuestra realidad.
Es correcto, sí. De hecho, mi experiencia, incluso cuando inicio en algunos proyectos, ni siquiera están listos, están en la etapa beta-alfa, y ya empiezo a identificar deuda técnica en esa etapa. Pero bueno, vamos a ir entrando en materia. Me gustaría Douglas como partir de una definición no tan rígida, ¿no?
qué es lo que opinamos nosotros de qué es la deuda técnica o al menos en el contexto de nuestra plática del día de hoy a qué nos estamos refiriendo con la deuda técnica. Te lo comento, básicamente la deuda técnica es como su nombre lo indica, una deuda, pero una deuda con quién? Es una deuda con nosotros, digamos, en el futuro. Es cuando tomas atajos en el desarrollo, normalmente,
Y decidís tomar ciertas, bueno, valga la redundancia, decisiones que te ayuden en el corto plazo, pero sabemos que a largo plazo son cosas que tal vez van a regresar y vamos a tener que prestarle atención. Entonces, vi por ahí una analogía donde decían que era como tomar prestado de las implementaciones que tenemos hoy en el futuro.
vamos a tener que pagar con esas decisiones que tomamos hoy. Y como para dar un ejemplo un poco más claro, porque está un poquito en el aire esta definición, normalmente es cuando tomamos una decisión de decir, sé que en un futuro mi aplicación no va a dar la talla con un millón de usuarios.
pero por ahora esto me funciona y lo voy a dejar así. Ese es como un bastante aceptable de deuda técnica, otro nivel menos aceptable es decir, funciona y no voy a agregar unit testing, más adelante lo hago, ese más adelante se empieza a postergar.
Entonces básicamente por ahí podríamos ir definiendo lo que es la deuda técnica, son todas estas decisiones que vamos tomando que hacen que nuestro código empiece a hacer menos flexible y sea más complicado ir agregándole cambios.
y que no sea tan robusto. No sé si tienes como una idea diferente, Douglas, o si quisieras agregarle algo a esta definición. ¿Qué es la deuda técnica para vos?
Douglas (05:40)
Si fíjate que no diferente, tal vez expandir un poco porque no es, y entiendo que vos lo veas en la parte de desarrollo, sin embargo no es, vos lo dijiste al principio, no es exclusivo para desarrollo, pero tampoco no es común solo en desarrollo. En la parte de sistemas y operaciones es muy común la deuda técnica y yo le agregaría a lo que ya mencionaste, es muy de acuerdo con ello, decisiones que vas a tomar.
Juan (05:50)
Mm-hmm.
Douglas (06:10)
y que al futuro vienen y te toca pagarlas, literalmente pagarlas. Yo le agregaría también que el tiempo produce deuda técnica, ¿en qué sentido? En el sentido de que existen paquetes de herramientas que van caducando, que van dejando de tener soporte y a medida pasa el tiempo te genera...
Juan (06:16)
jajaja
Douglas (06:39)
una necesidad y es necesidad de actualizar. No por querer tener la última versión, sino porque estás en una versión... Eso puede pasar en desarrollo. No estás en una versión de Node.js o una versión de tu framework o una versión del sistema operativo que está a punto de llegar a su finalización de soporte o end of life, como se le dice en inglés.
y vas dejando ese proyecto de lado, de actualizar por las diferentes razones, trabajo nuevo, fitos nuevos o cualquier otro tipo de prioridades y el tiempo en ese caso te generó una deuda técnica, no fue una mala decisión como tal, sin embargo el paso del tiempo...
como que fue el detonante para que se llegara al punto de tener una deuda técnica. Pero definitivamente, Juan, también quiero mencionar que en la parte de sistemas y operaciones se da mucho, desde una mala decisión.
lanzar una aplicación, pero no lo voy a hacer en cluster ahorita porque para que la lancemos rápido porque sólo va a tener pocos usuarios ahorita y terminamos necesitando un load balancer cluster y storage compartido, etcétera. Hasta otro tipo de decisiones como tal vez no dockerizar, algo que sabíamos que iba a crecer o que íbamos a necesitar segmentar.
Juan (07:50)
jajaja
mmm
Douglas (08:04)
y ejemplos hay muchos, pero definitivamente en cuanto a la definición estoy de acuerdo con lo que dijiste, le agrego eso de que el tiempo va generando eventualmente que se vuelva un detonante para crear una nueva deuda técnica y que en la parte del sistema se da mucho.
Juan (08:20)
Recuerdo mucho cuando la empresa Red Hat anunció que iban a descontinuar o ya iban a dejar de dar este sistema gratis que era CentOS y pusieron una fecha límite y pues ni modo, había que buscar otra alternativa. eso también creo que cae en la categoría de deuda técnica cuando ya
se está acercando el tiempo de que ya va a llegar a su fin y no lo has actualizado. Todas estas paquetes o dependencias, sistemas operativos que tienen un end of life ya pronto, pues se vuelven de una técnica.
Douglas (09:06)
Si se vuelven deuda técnica Juan y curioso que menciones eso, de hecho ahorita donde estamos todavía algún par de clientes tienen por ahí uno que otro servidor corriendo en Cento de Siete y están ahí y querés actualizarlos pero como son críticos se requiere de un plan más elaborado y es ahí donde ellos lo terminan empujando y prefieren correr el riesgo.
de estar trabajando en un sistema operativo sin soporte, lo digo porque en efecto tenés razón. Ese tipo de cosas, cuando no sea... De nuevo, el tiempo es como el detonante, pero luego se vuelve en parte nuestra... Cuando digo el tiempo, me refiero al paso del tiempo. Se vuelve el detonante.
pero luego se vuelve responsabilidad nuestra con el tiempo apropiado de planeación, implementar o actualizar para que no sea un problema. Entonces sí, sí, en efecto ocurre.
Juan (10:06)
Sí, sí, definitivamente.
Bien, definitivamente es curioso la deuda técnica. Es inevitable, también me gustaría dejar eso claro desde el inicio. Como ya dijo Douglas, el tiempo es inevitable, así que todas las dependencias que tenemos hoy en día se van a convertir en deuda técnica en el futuro. Y aquí es donde entra en juego las decisiones que vamos a tomar, cuáles dependencias vamos a tener, qué sistemas operativos, etcétera. Por ejemplo, yo trabajo
con ciertos paquetes de en Go que ya están en modo mantenimiento en su repositorio eso significa que solamente van a hacer alguna actualización si realmente surge algún problema de seguridad o algún problema muy crítico pero ya no van a agregar nada y lo utilizamos entonces sí es como una deuda técnica pero también está
esta famosa frase Douglas de si funciona no lo toques entonces eso condiciona mucho cómo actualizamos y qué cosas tenemos eso pasa muy seguido pero bueno me gustaría como que entráramos un poco en eso en ese tema Douglas en cómo surge la deuda técnica ya mencionabas un punto que es el paso del tiempo ⁓
también mencionábamos que hay paquetes que ya llegan a su ciclo de vida, al fin de su ciclo de vida, pero también hay ciertos puntos que pueden ser evitados desde mi punto de vista y que a veces es por problemas que hay en nuestro equipo. El primero que me gustaría mencionar es la, lo voy a decir de esta manera, la procrastinación para corregir bugs. ⁓
específicamente del desarrollo. Bueno, en este aspecto, obviamente mi punto de vista va a ser más orientado hacia el desarrollo y por eso mencionaba al inicio que Douglas nos brinda otra perspectiva y que nos ayuda a expandir este tipo de temas.
Pero bueno, hablando del desarrollo de una aplicación es muy normal que a veces tenemos ciertos bugs que no son tan problemáticos, que tal vez no evitan que los usuarios utilicen la aplicación.
o a veces son bugs que para corregirlos requieren nuestro tiempo de desarrollo más allá de uno o dos días. Y ya hemos encontrado como estos atajos para corregirlos, para dar como un ejemplo simple, digamos que nuestra aplicación tiene un bug donde cuando subís un archivo, el sistema no lo procesa correctamente.
Entonces nosotros tenemos que ir y digamos como que darle una patadita al sistema para que vuelva y lo procese correctamente. Pero investigar por qué sucede eso y luego corregirlo lleva tiempo. Entonces la maquinaria de hacer nuevos features no se detiene y decidimos no dedicarle ese tiempo.
y decimos más adelante. Entonces, por eso aquí es donde viene mi punto de procrastinar al momento de corregir estos pequeños bugs que aunque tenemos una solución
ahí medio parchada y medio por encima, realmente no estamos atacando el problema de raíz. Y eso, al menos en la parte de desarrollo de software, sucede mucho más de lo que me gustaría admitir y definitivamente es algo que va contribuyendo a esta deuda técnica que empieza a crecer, empieza a crecer en estas empresas grandes.
Y bueno, ese es como que mi punto de vista desde el lado de desarrollo Douglas, tu punto de vista desde, digamos, como desde el lado más cercano a los servidores y a los procesos y operaciones, ¿te parece que hay procrastinación en ese aspecto?
Douglas (14:27)
Sí, sí hay bastante, fíjate Juan, hay bastante y pasa...
o esto se viene a unir y enlazar con ejemplo que dimos anteriormente de paquetes, librerías o software enteros que llegan a su end of life, a su final de ciclo de vida y es que la procrastinación nos lleva a que eso sea un problema y yo sí creo que es intencional esa procrastinación porque preferimos trabajar en otras cosas.
Juan (14:43)
Así.
Douglas (15:03)
Y procrastinar muchas veces es una actitud de no querer hacer algo, pero no necesariamente es que no hago nada.
Juan (15:04)
Sí.
Douglas (15:13)
Estoy trabajando en nuevas funcionalidades, cosas que son más interesantes que me llaman la atención. Estoy trabajando en nuevas implementaciones o que tenemos un nuevo cliente y vamos a atender ese nuevo cliente. Y estoy buscando lo emocionante, lo interesante y voy dejando de lado todas estas tareas de mantenimiento que luego se vuelven un problema generando deuda técnica. Entonces, yo lo comparto con vos y definitivamente en el área del sistema se da mucho.
Juan (15:20)
Sí.
Douglas (15:43)
Y justo por eso, yo creo que vos mencionaste algo y me llama la atención que cuando llegaste nuevo te pusieron a ver ciertas cosas como para evaluar deuda técnica, creo que fue lo que mencionaste, o esos puestos similares.
Juan (15:45)
Sí.
Douglas (16:00)
Y realmente es que a veces es lo que se hace cuando llega un junior o una nueva contratación. Buscamos darle esas tareas que han estado ahí a veces por meses o años guardadas para que esta persona las saque porque nosotros no queremos trabajar en ellos simplemente por...
Juan (16:12)
Mhmm.
Douglas (16:19)
por buscar cosas más interesantes simplemente porque tal vez las vemos tediosas o aburridas. Entonces, de nuevo, la procrastinación no significa que es que no estoy haciendo nada. Simplemente estoy decidiendo intencionalmente darle prioridad a cosas que me gustan más hacer y no necesariamente a cosas requeridas para el departamento o para la empresa.
Juan (16:43)
Sí, y es que a veces este tipo de tareas de corregir un book, si no es muy crítico, no representa como un ingreso tan, un ingreso tangible para la empresa. Así que por eso a veces como que decidimos ir por otra. Bueno, pero ya vamos a hablar un poco sobre eso, de las prioridades que se van dando en el ciclo de nuestro sistema.
Por ahí he visto también Douglas que a veces sucede donde no sé si podríamos meterlo en este costal de que estamos hablando ahorita de la procrastinación de los errores.
En la parte de sistemas y servidores también tenemos como deuda técnica de hardware. Me parece que a veces se sucede donde tenemos, vamos a decir algo muy simple, tenemos unos discos duros, un cluster y tenemos discos duros que tal vez ya requieren cierta actualización, ya sea por el tiempo de uso o porque queremos cambiar un estado sólido dependiendo de los requerimientos.
Y de nuevo, ese tipo de actualizaciones, y más en el hardware, son bien complicadas. Entonces ahí como que mejor después. Después lo hacemos y vamos a encontrar otro tiempo de cuando hacerlo después. También pasa, ⁓
Douglas (18:09)
Fíjate que creo
que has tocado un punto bien interesante cuando se habla de hardware. En las empresas creo yo que en ese sentido es una procrastinación de la gente que maneja el dinero porque se requiere de inversión y entonces están queriendo sacarle el jugo lo más que puedan al hardware existente y pues por ahí va muchas veces el problema. Entonces...
Juan (18:30)
mmm
Douglas (18:36)
incluye a veces procrastinación o a veces quererle sacar mayor provecho o por mayor tiempo posible provecho a una inversión previa. Definitivamente es algo que se tendría que corregir y cuando las empresas ven de que el hardware nuevo consume menos energía, es más eficiente, las aplicaciones van a ser más rápidas y a medida pasa el tiempo realmente salva más dinero invertirlo.
Pero viene esa parte como tal, cuando trabajas en una empresa que tiene su propio data center, viene mayormente de la gente que administra el dinero. Y aquí se combina temas que hemos tocado en el pasado, que es nosotros saber presentar el problema, saber presentar el proyecto y llevar soluciones para que la gente que maneja el dinero lo pueda entender. Ahora, lo otro que me gusta de este tema que has tocado en cuestión de hardware es que lo creas o no también pasa en la nube.
Juan (19:14)
viene de arriba
Douglas (19:36)
también pasa en la nube y pasa bastante. ¿De qué manera? Vos tenés una instancia o un grupo de instancias corriendo para X aplicación y tienen, ponéle año y medio corriendo. Entonces, tal vez para esta fecha AWS o cualquiera que sea tu proveedor ha lanzado una o dos generaciones nuevas de esa misma instancia. Esta nueva generación de instancias son más baratas, más eficientes.
Juan (19:36)
Ok, ok.
Douglas (20:06)
Entonces, por ende, te conviene migrar tu aplicación a la nueva generación de instancias. Pero volvemos a lo mismo, tal vez procrastinación, y ahí sí puede ser de parte nuestra, como personal técnico, procrastinación o por lo tedioso que es. Y también hay que tocar el tema, Juan, no sé si lo expandimos ahorita o más adelante, pero también hay que tocar el tema la parte de negocios. Muchas veces son aplicaciones o servicios.
Juan (20:09)
Sí.
Douglas (20:35)
que no podemos tocar ahorita, tal vez es temporada alta y ese sistema no puede estar abajo ni un minuto. Al menos no planear tocar nada por nuestra parte o simplemente es algo muy crítico y cuesta programar el mantenimiento para actualizar. Pero volviendo al punto principal, la deuda técnica con hardware pasa también en la nube. También hay nuevo tipo de almacenamiento o disco duro.
Juan (20:42)
Sí.
Douglas (21:04)
y ocupas actualizar hardware también en la nube y aunque no se hace el trabajo físico de ir a montar el hardware a un rack, conectarlo e instalar cosas, hay que estar también actualizando el hardware porque eso nos va a generar no sólo mejor rendimiento, pero también nos va a reducir costos.
Juan (21:07)
Sí.
Es cierto, Qué curioso, a veces pensamos que la nube es como que muy mágica, no, son otros servidores y ya.
Douglas (21:31)
son servidores que no tengo yo que instalar o administrar, pero son servidores.
Juan (21:38)
Creo que podríamos pasar al siguiente punto que quería tocar, que creo que va un poco ligado con lo que estabas hablando y es que otro motivo por el cual se da la deuda técnica
que no tiene que ver tanto con el desarrollo o nuestras habilidades técnicas es la poca planificación y es que cuando no se planifica empezamos a hacer un sistema y aquí cuando digo sistema me refiero a todo, la programación, configuración de servidores, todo un poco medio improvisado y porque no tenemos un rumbo, no tenemos como una fecha para una tarea en específico y sí se van definiendo
tareas, claro que sí, pero no hay una planificación que tome en cuenta probablemente esto de la deuda técnica y eso creo que es uno de los motivos más grandes desde mi punto de vista. Hay maneras para corregirlo, ya lo vamos a ir viendo más adelante, pero en general
no se suele planificar mucho y esto yo creo que va ligado también con lo que mencionabas que para los que están en los altos puestos es difícil o quieren exprimir lo más que se puede el costo de lo que ya está dado entonces cambiar algo, migrar a otro lado involucra tiempo hay que pagar a los técnicos, a desarrolladores, que un nuevo hardware, etc.
Aquí es donde también tenemos nosotros que tratar de convencerlos y llegar a un consenso, a un punto medio donde podamos planificar este tiempo para...
atacar la deuda técnica. Porque la deuda técnica es una deuda como cualquier otra deuda en el banco donde si la dejas sigue creciendo y creciendo y los intereses son bien fuertes. eso es algo que yo visto mucho Douglas y pasa mucho demasiado la poca planificación. No se le da tiempo para, o sea, ni siquiera cruza por nuestras mentes tener un tiempito para revisar la deuda técnica
Douglas (23:39)
Sí, sí.
Juan (23:57)
y cómo minimizarlo.
Douglas (24:01)
Sí, fíjate que la poca planificación, Juan, en mi opinión, es un factor o probablemente el factor más grande que genera la deuda técnica. La procrastinación afecta mucho, el paso del tiempo, de nuevo, genera un... es un detonante que si no se maneja bien genera deuda técnica.
pero en la planificación recae que lo puedas coordinar o no. Y la falta de planificación, y esto es por lo cual yo creo que es el factor más grande, por el cual se genera la falta de planificación a diferentes niveles.
no solo en coordinar que se pueda atacar la deuda técnica que ya existe, fíjate, sino en evitar que se genere nueva deuda técnica desde la planificación de una nueva aplicación o una nueva funcionalidad. Desde que estás en ese tiempo y se hace un estimado, muchas veces no se deja tiempo, no se aparta tiempo para arquitectar.
pensar bien los diferentes componentes y elementos y eso nos lleva a tener un producto final que no cubre todas las necesidades o que no va a escalar, no va a ser fácil de escalar al siguiente nivel cuando la aplicación esté lista para el siguiente nivel por la pobre planeación. Entonces cuando ya se acerca el deadline o la fecha de entrega o fecha de lanzamiento efectivamente y comprensiblemente el negocio pide que se publique lo que está.
Juan (25:23)
Sí.
Douglas (25:39)
Y eso sería una carencia nuestra en ese sentido. Y pasa en la solución de software, en su diseño y arquitectura, y también pasa a eso en la solución de infraestructura, en su diseño y en su arquitectura. Entonces, esta pobre planeación nos lleva a...
Juan (25:54)
Mm-hmm.
Douglas (26:01)
que rápido se genere una deuda técnica o que muchas veces estamos publicando la nueva funcionalidad, estamos publicando el nuevo software y de antemano nosotros ya sabemos qué partes hay que refactorizar o volver a hacer o qué partes hay que retocar, pero no estamos planeando cómo hacerlo. Y agregado a eso...
y por qué la planeación sigue siendo ese factor principal, mi opinión, asumiendo que fue un lanzamiento exitoso, asumiendo que bien diseñado, bien arquitectado, acorde a las necesidades actuales y crecimiento para el futuro, no se planifica mantenimiento.
muchas veces no se planifica mantenimiento de los diferentes elementos, componentes y tal vez cuando estemos en la parte de dar consejos de cómo evitar la autotécnica vamos a profundizar en eso, pero el mantenimiento es importante, como para los que tienen vehículos, es como tu carro, si no haces mantenimiento eventualmente las cosas se van a dañar y cuando no se planifica mantenimiento de algo recién lanzado
eso es, está garantizando deuda técnica a corto o mediano plazo. Entonces, en los diferentes niveles que conlleva tanto planificar atacar la deuda técnica como planificar nuevas soluciones, casi que nos estamos preparando para buscar la deuda técnica en ese sentido muchas veces. Y definitivamente, Juan, eso es un comportamiento que en los departamentos técnicos tenemos que cambiar.
Juan (27:46)
Sí, generalmente. Muy curioso lo que decís porque...
No es lo mismo dedicarle el tiempo a corregir bugs que aparecen. De la nada un usuario reportó que no se puede registrar a nuestra aplicación y investigamos y lo corregimos. No es lo mismo estar apagando incendios a prevenirlos. Y creo que es cierto, a ese punto no se le dedica tanto tiempo a tratar de prevenir este tipo de cosas.
y mejorar las bases de nuestro sistema, sea en infraestructura como en el desarrollo también.
Douglas (28:25)
Y a veces es muy importante Juan, y perdón
para asegurarme de mencionarlo, muchas veces saltamos rápido a culpar los jefes o los project managers o a veces al mismo cliente y decir es que no nos dieron el tiempo para solucionarlo bien, les dijimos que esto iba a fallar y nos dijeron que siempre lo lanzáramos así, pero a veces se nos olvida que fuimos nosotros quien dimos el estimado de cuánto iba a tomar, fuimos nosotros los que dijimos que esa fecha se lanzaba.
Juan (28:37)
Mm-hmm.
mmm
Douglas (28:55)
fuimos nosotros los que por negligencia, por descuido, porque no lo vimos, no nos percatamos de esos problemas y hasta que estamos cerca del lanzamiento lo vimos y a esas alturas el negocio ya requiere que se lance. esas alturas ya el negocio requiere solución y en ese momento querer parar un lanzamiento por algo que tuve que haber visto antes, pero si yo hubiese comenzado diseñando la solución.
en el momento del diseño de la solución ahí se identifica y si yo pedí dos semanas para lanzar algo.
y en el primero o segundo día que estoy diseñando la solución, identifico que hay algo más grande y que en lugar de dos semanas va a tomar cuatro, en ese momento yo puedo levantar la bandera roja y decir, no vimos esto, miren, esto va a ser un problema, hay que volvernos a sentar y volver a generar tareas. Pero entonces eso, muchas veces brincamos a culpar y creemos que porque lo vi dos días antes del lanzamiento, cuando era mi responsabilidad ver
al inicio, creemos que con eso le puedo echar la culpa a los gerentes o a los project managers o a los clientes y en efecto de nuevo algo a considerar y algo a cambiar de nuestra parte.
Juan (30:13)
Totalmente de acuerdo, requiere que el equipo entero cambie su mentalidad y que tratemos de mejorar todos. Bueno, me gustaría dar como un último punto, hay muchos que afectan a la deuda técnica, para efectos de esta plática me gustaría dar un último punto que, este sí afecta directamente a lo que es la programación.
y es que ya han salido muchos papers, salido muchos artículos, anécdotas de personas que dicen donde...
el uso de la inteligencia artificial ha incrementado la deuda técnica. Y tiene sentido porque se ha visto un incremento de código duplicado dentro de los sistemas. Se ha visto un incremento de código que no se puede mantener o que los mismos desarrolladores no entienden.
Entonces, ¿cómo puedes darle mantenimiento a algo que no sabes muy bien cómo funciona? Entonces, sí, ya se han visto muchos artículos que lo dicen con números. Me hubiese gustado traer tal vez un número más específico, pero definitivamente con una búsqueda rápida pueden encontrar que el uso de AI ya está siendo un problema en cuanto a la deuda técnica. Y este sí es un problema bastante nuevo, así que...
es complicado tratar de afrontarlo porque si estamos en un grupo de trabajo donde se ha decidido utilizar mucho la inteligencia artificial como parte de nuestro flujo de trabajo pues creo que la solución no solamente es decir ya no la utilicen
ya la solución es un poco más compleja. Y aquí sí, bueno, de mi parte es un poco complejo de nuevo decir qué tienen que hacer porque ⁓ yo no la incluyo en mi flujo de trabajo, así que no tengo tanta experiencia con ese tema. Pero sí, definitivamente las inteligencias artificiales generativas...
están generando deuda técnica y es algo que hay que tomar en cuenta si están planeando utilizar la inteligencia artificial como parte de su flow. Es algo que hay que tener en cuenta y hay que desarrollar algún plan al respecto.
También se está utilizando Inteligencia Artificial, verdad Douglas, en la parte de infraestructura, si no me equivoco. He visto, al menos, bueno no sé si es puro marketing, pero he visto soluciones donde están hablando de mediante Inteligencia Artificial, generan la infraestructura y desarrollan las, perdón te genera las configuraciones necesarias. Pero me pongo a pensar yo tomando en cuenta esto, una configuración de un servidor
donde se va alojar el sistema de pagos y es una configuración que yo no la manejo al 100 % pues me asusta un poco Douglas, no sé si estoy siendo muy boomer en este momento pero sí es algo que me pone a pensar y tal vez hay que planearlo mejor eso es lo que pienso yo
Douglas (33:26)
Fíjate que de acuerdo y yo creo que no solo en desarrollo, yo creo que en desarrollo pasa más definitivamente y es más evidente que el uso de Inteligencia Artificial está generando deuda técnica, pero también como acaba de mencionar se usa bastante en la parte de sistemas y en configuraciones desde preguntarle a la Inteligencia Artificial cómo hacer un...
una regla en NGINX hasta configuraciones más complejas para crear infraestructura con Terraform o administrar con Ansible hasta el cielo, el límite es el cielo. Lo que yo sí quiero aclarar aquí, Juan, es de que no es la inteligencia artificial como tal quien ha creado esta deuda técnica o este problema.
Juan (34:08)
Sí.
Douglas (34:21)
sino las personas que le dan mal uso a la inteligencia artificial. Yo quiero, y creo que probablemente esa termina siendo la respuesta a qué hacer. Una respuesta simplificada conlleva más, conlleva más los detalles son más complejos tal cual, ¿verdad? Pero, pero el uso apropiado evita, evita eso.
Juan (34:39)
Sí, los detalles son más complejos, obviamente.
Douglas (34:51)
Ya lo discutimos en muchos episodios atrás, formas en las que nosotros utilizamos la Inteligencia Artificial y hemos mencionado de que no podemos usar algo que la Inteligencia Artificial nos da que no entendemos.
que no entendemos a cabalidad. Tiene que ser al final del día 100 % mi trabajo. Yo tengo que entender 100 % del código, de las configuraciones que voy a utilizar y que voy a implementar con la inteligencia artificial, porque éticamente se vuelve lo mismo que cuando buscábamos en Google. Y solo hacíamos copy-paste de la respuesta en Stack Overflow comparado con agarrar de la respuesta de Stack Overflow lo que yo necesito.
y entiendo para mi solución lo mismo con la Inteligencia Artificial. Y está generando problemas más grandes Juan, no solo de la técnica, está generando bastantes problemas de seguridad, por ejemplo, porque se está enfocando en la Inteligencia Artificial, se enfoca en responder lo que le pediste.
Juan (35:45)
Sí, sí, sí.
Douglas (35:52)
Y por más que vos le digas que lo haga seguro contra ataques y cosas, no va estimar todos los escenarios. Si no vas como ingeniero a revisar cautelosamente y el 100 % del código o configuraciones que te generó la inteligencia artificial, vas a generar un problema de seguridad, vas a generar una deuda técnica, vas a generar posiblemente problemas en producción, problemas grandes.
de que cuando el error cae, cuando nos llega el error, no sabemos qué está pasando porque no entendimos lo que estamos haciendo. Y eso es delicado. Vos lo dijiste eso ahorita, que te genera un miedo tener el servidor configurado que va a generar transacciones de tarjeta de crédito o transacciones delicadas y tener ese servidor que se configuró como inteligencia artificial.
Yo también tuviera miedo, yo también tuviera miedo, a diferencia de que quien lo configuró se apoyó de la Inteligencia Artificial para configurarlo, esa es una historia totalmente diferente, pasa bastante pero yo quiero resaltar eso, no es culpa por sí sola de la Inteligencia Artificial, es culpa de los profesionales que no la utilizan adecuadamente.
Juan (37:08)
Sí, creo que la inteligencia artificial actualmente como la está vendiendo la industria...
te da esa falsa seguridad o al menos a las personas que no son tan... no tienen tanto cancheo como decimos, que vienen empezando, les da esta falsa seguridad de sin saber desarrollar algo lo podés hacer y yo creo que no es así. Yo creo que cómo podés identificar que la inteligencia artificial está haciendo un problema si no tenés experiencia. Cómo podés identificar un PR, un pull request donde hay algún error
no conozco el lenguaje, si no conozco la lógica que hay detrás, entonces es necesario, como decías, utilizar la inteligencia artificial como una herramienta y no que la inteligencia artificial nos utilice a nosotros como un medio para llegar a donde quiere ir. Bueno, definitivamente este es un tema que da para mucho y es así, ¿no? Es lo nuevo que tenemos hoy en día en nuestra industria y creo que por lo menos hay que tener cuidado.
hay que saber cómo utilizarlo. me gustaría pasar entonces Douglas a qué hacer. Ya sabemos que hay deuda técnica, ya dijimos que siempre va a haber deuda técnica en cualquier proyecto, entonces ¿cómo lo minimizamos? No quiero hablar de eliminarlo porque incluso si lo logramos eliminar en cierto punto es probable que el día siguiente ya tengamos de nuevo la deuda técnica.
Entonces, ¿cómo minimizar? Me gustaría empezar, entonces, Douglas, con algo que he aprendido con el tiempo y es definir qué es la deuda técnica para tu equipo y para la empresa en específico. ¿A qué me refiero? Por ejemplo, para cierto grupo de desarrollo, para cierta empresa,
Podría ser que una deuda técnica sea que nuestro sistema no tenga el 90 % de unit test, la cobertura del 90%. Pero para otra empresa tal vez es menos. Entonces, ese tipo de cosas hay que definirlas. Si tenemos un paquete, una dependencia, pero no hemos identificado que tiene una vulnerabilidad encontrada. No se ha encontrado una vulnerabilidad.
pero es un paquete que, como te decía antes, está en mantenimiento. Eso es una deuda técnica, sí o no. Entonces, yo creo que de entrada lo que se tiene que hacer es tener como bien definido dentro de nuestro equipo de trabajo cómo identificar y priorizar qué cosas requieren nuestra atención y cuáles tal vez todavía no. Ya dijimos que podría ser procrastinación, pero no, al final del día no podemos hacer todo al mismo tiempo.
tenemos que darle cierta prioridad y definir cuáles requieren nuestra atención más inmediata y cuáles podemos atacarlas más adelante. yo Douglas diría que podríamos empezar con eso en nuestro trabajo, en nuestro grupo, en definir qué consideramos que es una deuda técnica y cuál, qué cosas hemos identificado como deuda técnica que requieren atención más inmediata.
Porque luego, se lo decimos a los project managers, a los product owners? Todos estos puestos que son los que luego dictan para dónde va el ciclo de desarrollo, ¿cómo podemos nosotros hablar con ellos si internamente el equipo técnico no lo ha definido? Entonces, yo creo que ese podría ser nuestro punto de partida.
Douglas (41:01)
Sí, sí, fíjate que muy de acuerdo, muy de acuerdo y fíjate que yo quiero dar otro consejo que va de la mano con esto porque comienza con lo que vos estás diciendo porque una vez que has definido que para tu equipo, para tu aplicación, cuál es la deuda técnica o qué es deuda técnica en general, eso te permite luego no solo crear el plan para atacarlo.
Juan (41:11)
Ok.
Douglas (41:27)
resolverlo, buscar minimizarlo, pero también buscar evitar que continúe. Y algo que nosotros hacemos bastante, donde yo trabajo es creamos una rutina de mantenimiento o un plan de mantenimiento, nosotros le llamamos routine maintenance plan para cada aplicación o para cada...
Juan (41:48)
Ok.
Douglas (41:52)
sitio web para cada herramienta o parte de infraestructura se crea un plan de mantenimiento y que incluye este plan de mantenimiento y se documenta se pone por escrito por cierto pero esto incluye por ejemplo digamos agarramos un sitio de WordPress como ejemplo y esto luego lo aplicamos a cualquiera que sea tu solución tu herramienta o parte de infraestructura o servicio que querés hacerlo
Pero un sitio de WordPress, entonces, hacemos un plan de mantenimiento donde dice, cada tres meses se van a actualizar plugins. Por ejemplo, también se pone cada tres meses se va a actualizar la WordPress Core, la versión de WordPress. Cada seis meses se van ⁓ a actualizar el sistema operativo de los servidores donde está corriendo WordPress. Las versiones menores.
Juan (42:28)
Ok.
Douglas (42:50)
Una vez al año se va a hacer actualización de versiones mayores en lo que es ponerle Redis, MariaDB e incluso paquetes del sistema operativo. Y tenés eso marcado con tiempo, cada cuanto vas a manejar esas cosas. Ese plan de mantenimiento incluye también...
Juan (42:59)
Ok
Douglas (43:15)
¿Cómo reaccionar si se descubre una vulnerabilidad nueva? Y si es crítica. Entonces eso va a decir, más tardar, el siguiente día, ese mismo día tiene que estar en preproducción. Y a más tardar, el siguiente día tiene que estar en producción. En cada una de estas capas que te mencioné, vulnerabilidad en plugins o en wordpress core, o vulnerabilidad nivel de sistema operativo, o paquetes, herramientas, etcétera.
También incluye el tiempo estimado de cada una de estas tareas. Actualizar plugins cada tres meses, entonces dependiendo de qué tan grande es el sitio, se tiene estimado, no sé, de 4 a 12 horas. Porque si solo toca actualizar los plugins, lo haces rápido. Si toca actualizar la mayoría, te toma las 12 horas, le agregas un rango. Y así a cada tarea.
Y ese plan de mantenimiento lo revisa el arquitecto de software o la persona encargada en la parte del software, lo revisa la persona de sistemas, lo revisa la project manager, los diferentes stakeholders y termina llegando al cliente y el cliente lo aprueba. ¿El qué está probando? Que está de acuerdo con lo que dice y está probando el tiempo también.
Juan (44:31)
con el plan.
Douglas (44:34)
que se va a utilizar. Se crean tareas, nosotros usamos un software que se llama Teamwork para administrar los proyectos, se crean las tareas que están asignadas y ya tienen un deadline definido. Y dos semanas antes o un mes antes, comienzan a alertar a las personas de que hay que trabajar en los mantenimientos de esa aplicación en particular. Entonces eso, Juan, esa planeación
que nace de haber identificado que es una duda técnica para un sitio de WordPress, que es lo que vos nos decías, eso cuando una vez que se identificó...
implementando ese plan de mantenimiento, nos aseguramos de que cada aplicación, cada sitio web, porque puse el ejemplo de un sitio de WordPress, que lo manejamos más o menos de esa manera, pero de nuevo lo hacemos con clústeres de Kubernetes, lo hacemos con clústeres web en instancias Easy Tools, lo hacemos con clústeres de MariaDB, en Galera, etcétera, etcétera, ¿verdad? Lo hacemos de la misma manera y ya está programado cómo se va a estar dándole mantenimiento.
Juan (45:24)
Claro.
Douglas (45:42)
a estas tareas para evitar que se genere deuda técnica y por cierto lo olvidaba y se incluye revisitar los scripts de CICD, el scripts que le hace build a la aplicación, revisitarlo, revisitar la versión de PHP y Node.js todo eso va incluido en el plan de mantenimiento para asegurarnos que no nos genere deuda técnica entonces yo, ese sería probablemente uno de los consejos más grandes que yo daría acá.
Juan (45:53)
Ok.
Douglas (46:11)
Asegúrense de crear ese plan de mantenimiento para cada una de las aplicaciones o infraestructura que manejan y asegúren que eso usted ya ha probado. Yo no necesito preguntarle a nadie cuando ya llegue el momento de ejecutar estas tareas de mantenimiento, no necesito preguntarle a nadie, ¿le doy prioridad a esto o le doy prioridad a otra cosa? No.
Ya está acordado que cuando toca esa es la prioridad, las tareas de mantenimiento y de esa manera Juan se reduce significativamente la deuda técnica.
Juan (46:45)
Excelente. sea, en pocas palabras, como para irlo viendo de una manera más generalizada, podría decir que...
se definió cuáles eran los puntos que generan deuda técnica y luego se le asignó una prioridad a cada uno de ellos y en base a eso se le asignó, bueno, tal vez no prioridad pero un peso y en base a eso se va definiendo cada tanto, qué tiempo se va a ir actualizando cada uno de ellos, cuánto tiempo me va tocar realizarlo y una vez aprobado pues ya no hay que pedir permiso, ya está definido.
⁓ que plan muy ingenioso, verdad. Muy curioso.
Douglas (47:30)
y muy
útil, cumple su propósito y lo cumple hasta el momento, lo cumple muy bien.
Juan (47:36)
Sí, si estás actualizando redis o la base de datos cada año, siempre estás con una versión que no estás en la última versión, pero estás en una versión bastante reciente. Qué curioso, muy bueno.
Douglas (47:52)
Sí.
Juan (47:57)
Ya habías mencionado, igual me gustaría como para dejarlo más que claro durante esta plática. Otra manera que podemos hacer es el hecho de, como ya decías, integrar la etapa de testing, de pruebas, dentro del desarrollo de una tarea. ¿Qué queremos decir con esto? para dejarlo un poco más claro, si a mí me dicen, ok, te toca hacer el login de un usuario. ⁓
estoy pensando en el tiempo que me va tocar hacer el formulario en HTML, CCS, JavaScript, porque lo voy a hacer sin utilizar frameworks, el tiempo que me va a tocar hacerlo en el backend y lo voy a hacer con PHP y las tablas que tengo que hacer en MariaDB y a ese tiempo yo debería agregarle también una etapa de pruebas ¿por qué? porque durante esas etapas de prueba vamos a ir identificando posibles errores, bugs que como decíamos al inicio tal vez no son críti-
pero si los dejamos ahí van a ir acumulándose acumulándose y luego va ser más difícil tratar de corregirlos porque tal vez más adelante dentro de tres seis meses ahora nuestra aplicación tiene una dependencia muy grande de otros sistemas de otras partes y ya cambiar eso es muy difícil entonces bueno Douglas lo ha repetido varias veces y creo que en otros episodios también lo has mencionado
Y sí, definitivamente incluirlo en lo que estamos cotizando, en el tiempo que estamos cotizando de nuestra tarea es fundamental. Y yo te diré Douglas, debo admitir que yo soy alguien que a veces olvido de incluir eso. A mí me pasa, no sé si a otras personas les pasará, que a veces trato de priorizar cumplir con todas las tareas. Vamos a decir, me dieron el login, me dieron el formulario de registro,
me dieron el formulario de actualizar los datos. Entonces yo priorizo terminar eso en un tiempo estimado y dejo por fuera el testing. Eso me ha pasado muy seguido. Bueno, ahora trato de incluirlo de un tiempo para acá, pero sí debo admitir que he sido culpable de eso. Y hay que tenerlo en cuenta. Es bueno tenerlo cuenta siempre.
Douglas (50:19)
Sí, no es necesario tenerlo en cuenta y esto va de la mano Juan, no sé si tal vez vos lo habías considerado a discutirlo, pero va de la mano como consejo para evitar la duda técnica que es una buena planificación, una buena planeación de...
nuevas soluciones, nuevas aplicaciones o nuevas funcionalidades que incluya esa buena planeación debería de incluir tiempo suficiente de análisis y diseño, de arquitectar la solución, tiempo suficiente para crear los diferentes tests que se necesitan, tiempo suficiente para...
solución, que también son cosas que ayudan a aliviar la deuda técnica porque muchas veces si no se documenta cómo hacer algo no sabes qué, no sabes qué, hay que hacerlo hasta que alguien, hasta que que falla y alguien se queja. Pero definitivamente va de la mano con lo que estás diciendo con eso, con una buena planeación y ese sería, yo le agregaría lo que estás diciendo como consejo a eso.
Juan (51:03)
Sí.
Sí.
Douglas (51:27)
una planeación efectiva de nuevas funcionalidades, de nuevos lanzamientos o nuevos productos, una planificación efectiva que nos ponga ya encaminados a reducir en la mayoría o en lo que dependa de nosotros a reducir esa deuda técnica o que se genere esa deuda técnica.
Juan (51:47)
Exacto, la meta aquí es reducir, reducir lo más que se pueda y de cierta manera controlar porque con el plan que nos compartiste es una deuda técnica controlada. esa sería como la finalidad total, la más grande finalidad de esto.
Douglas (52:07)
Gracias.
Juan (52:08)
Otro
aspecto que ayuda a minimizar la deuda técnica es un poco más relacionada a tal vez al backend. que también se da en el frontend, pero el hecho de modularizar nuestro sistema y qué quiero decir con eso, la idea es de tener un módulo, es un pedazo de funcionalidad de nuestro sistema que de cierta manera puede funcionar
o dejar de funcionar sin afectar al resto.
¿Por qué lo incluyo aquí? Porque pareciera que va más ligado al diseño de sistemas, la arquitectura de sistemas, sin embargo el hecho de tener este tipo de diseño nos ayuda a que la deuda técnica es más fácil de manejar y es más fácil de atacar, de controlar en nuestro sistema porque si tenemos una dependencia, doy un ejemplo rapidito. Yo estaba trabajando en un microservicio
que tenía una dependencia de un paquete que se conectaba a Redis
este servicio era el único que se conectaba a Redis. Entonces los demás servicios no necesitaban esa dependencia. Así que cuando tenía que actualizar o corregir o modificar algo que tenía que ver con Redis, yo solo iba a ese microservicio. Entonces el resto no se veía afectado por eso. ¿Qué pasa si luego, bueno, con lo que sucedió hace, bueno fue hace un año, ¿no? Con lo de Redis y toda esta polémica que había y muchas personas
migraron, qué pasa si yo hubiese querido cambiar la implementación de Redis y pasarme a otra a otra, Como Memcatch que es bastante también famosa.
pues hubiese tenido que modificar solamente el código de ese servicio. Entonces, eso es una de las grandes ventajas de los microservicios, pero también aplica a sistemas monolíticos que están modularizados por dentro. Entonces, es muy importante saber arquitectar o diseñar nuestro sistema de manera de ir minimizando estas interdependencias que luego es más difícil de modificar. Porque el hecho de migrar
o actualizar una nueva versión de un paquete Douglas lo que da más pereza y lo que lo vuelve más riesgoso es cómo afecta a todo el resto del sistema. Entonces nuestra meta aquí es buscar que ese riesgo sea mucho más contenido en un solo punto y sea más fácil de controlar.
Pero bueno, aplica donde es más fácil de verlo es en el backend con microservicios. En el frontend también sé que se puede. Y bueno, en la arquitectura de servidores también se puede hacer, estoy seguro. No tengo nada experiencia ahí, pero sí he visto cómo comentarios que hace la gente sobre ese tipo de diseños. No sé cómo se puede implementar mucho
mucho, muy bien ahí Douglas.
Douglas (55:23)
Sí, definitivamente sí se puede implementar y creo que es parte de un diseño inteligente que facilite el mantenimiento y lo venimos diciendo a lo largo de la charla, la discusión. El saber planear una solución que va a reducir esa deuda técnica conlleva esa arquitectura inteligente que facilite el mantenimiento y tal cual lo decís.
para actualizar algo o para hacerle cambios a alguna parte o una funcionalidad de la aplicación o de tu infraestructura. Toca afectar todo, toca reiniciar todo. Eso por sí solo va a ser complicado que el negocio nos deje hacerlo y se va a generar una deuda técnica en poco tiempo. Y una deuda técnica difícil de atacar.
por lo mismo, porque afectamos demasiados sistemas o servicios al mismo tiempo. Definitivamente, en la parte de infraestructura pasa. Y la manera de hacerlo es, los clústeres, ejemplo, son parte de eso, Juan, son una forma de hacerlo, porque vos podés hacer mantenimientos, actualización de paquetes enteros.
y los haces un servidor a la vez o un par de servidores a la vez sin afectar el tráfico. Entonces eso por su cuenta te permite hacerlo. La implementación de contenedores, definitivamente es otra de las maneras de hacerlo con orquestradores. Aun dentro del orquestrador si ocupas actualizar la misma versión de Docker o la misma versión de Kubernetes, agregas nuevos nuevos al clúster.
que ya estén actualizados y va sacando los nodos viejos con la versión anterior y de la misma manera segmentar o separar, usar automatización de manera inteligente que facilite el actualizar o el mantener...
Juan (57:11)
Ok.
Douglas (57:25)
sincronizado diferentes servicios es parte de ese diseño inteligente dentro de que es el área de infraestructura. Hay muchas maneras de hacerlo y definitivamente cuando no está ese diseño inteligente es complicado. Y aquí quiero mencionar Juan que muchas veces...
heredamos esa deuda técnica. Son diseños desde antes que estemos nosotros en la compañía o no fuimos nosotros quien diseñó esa solución, esa aplicación, esa arquitectura y lo heredamos y ahora nos toca a nosotros ver cómo hacerlo y es ahí donde aplican...
Juan (57:50)
Sí.
Douglas (58:01)
los consejos que estamos dando desde el primero que vos diste que es identificar que es una deuda técnica para mí y comenzar no ser dirigente y empezar a hacerlo pero si quiero mencionar que a veces heredamos esa deuda técnica y no importa quién la creó si yo la heredé y ahora yo soy el dueño lamentablemente ahora me toca a mí buscar minimizarla pero definitivamente un diseño inteligente
Juan (58:13)
Es cierto.
Douglas (58:29)
una arquitectura inteligente, concuerdo con vos Juan, es una manera de evitar que crezca una duda técnica.
Juan (58:37)
Sí, sí, definitivamente. Y es cierto, muchas veces generamos, llegamos a un empleo nuevo y nos damos cuenta que, wow, tienen ciertas cosas que no nos gustan. Pero bueno.
Y siguiendo, me gustaría dar como un consejo de mi parte, o bueno, no consejo, es más como un punto que me gustó mucho, que he visto de cómo minimizar la deuda técnica. Y esto es algo que sí aplico yo todos los días, Douglas, y es el hecho de atacar esta deuda técnica solamente cuando impactan directamente a la tarea en la que estoy trabajando. ¿Qué quiero decir? Digamos que me asignan una tarea donde tengo que refaclar
actualizar cómo inician sesión los usuarios. Entonces, como estoy tocando código que tiene que ver con usuarios, puedo darme la tarea de identificar si hay algo que requiere ser actualizado. O tal vez yo ya sé. Yo ya sé que, ⁓ OK, yo recuerdo que en esta parte hay una parte del código que debería ser mejorado o actualizado.
como ya estoy tocando este parte del código entonces ahí es donde yo aprovecho y actualizo ya sea el paquete o mejor la...
que está en el sistema, agrego unit testing que hagan falta, etcétera. Trato de hacer algo que vaya mitigando esta deuda técnica. Pero el hecho de enfocarte solo en las partes que impactan tu tarea actual, hace que el mantenimiento sea más fácil, porque ya no tienes que cambiar el contexto. El context switching, le llaman en inglés, y es algo que
nos hace perder tiempo y hace que perdamos a veces la brújula, pero cuando estáis en el mismo contexto es más fácil. yo actualmente tengo esa forma de tratar de atacar la deuda técnica y es si estoy trabajando en una parte del código y sé que lo puedo mejorar, lo hago. Tal vez tenemos dentro del source code, tenemos funciones que han sido mejoradas.
teníamos una función, hicimos una nueva función que hace lo mismo pero tal vez de otra forma utiliza otro paquete etcétera entonces yo a veces llego a ciertos endpoints que están utilizando las funciones viejas que funcionan en falta de redundancia pero entonces las empiezo a cambiar a la nueva función que ya tenemos que ya estamos empezando a estandarizar etcétera
y así pues eso es lo que trato de hacer y de esa manera como te digo es más fácil es cuesta menos identificar los errores y todo está en un solo punto también vale la pena mencionar lo que cuando hacemos el cambio y lanzamos un pull request también es más fácil para nuestros compañeros revisar nuestro pull request porque todo el código normalmente está en un solo punto
y tiene que ver con lo mismo, pues no dejamos de lado el hecho de colaborar de manera efectiva con nuestros compañeros.
Douglas (1:01:48)
Sí, si fíjate que me gusta, me gusta ese consejo y yo lo uso, fíjate Juan, yo lo pongo en práctica porque es ese principio de limpiar lo que acabo de usar, por ejemplo, ¿no? Si el plato en el que comí...
de comer lavarlo y entonces no estoy acumulando más platos sucios pero a la vez de camino si hay un vaso sucio entonces aprovecho a lavarlo porque ya estoy ahí me va tomar 20 segundos más o si voy caminando de mi cuarto a la sala y me encuentro unos zapatos en el pasillo los agarro y los pongo porque ya voy pasando por ahí y ese ha sido mi pensamiento
al momento de aplicar este tip que vos nos estás dando y me pasa bastante justo como vos lo estás diciendo, tal vez me enseñen alguna tarea de hacerle un cambio a un CI-CD pipeline y veo que no está con los estándares que definimos recientemente, aprovecho a ponerlo entre los estándares o veo que hay un warning.
está fallando pero hay un warning porque tal vez una función o un paquete va a alcanzar su fin de ciclo o simplemente no le gusta mucho de esa manera pues corríjole warning mientras hago el cambio y muchas veces son un par de minutos más muchas veces tal vez sí es media hora una hora más pero entonces cuando lo identifique pido ese tiempo de más
antes de decir cuánto va a tomar la tarea que me pidieron para de un solo hacerlo. Entonces, ese definitivamente es uno que yo lo uso bien intencional, soy bien intencional al respecto y es como sacarle un máximo provecho, de hecho, a mi tiempo. Siento que lo estoy sacando mayor provecho a ese momento ya que ya estoy ahí aprovechando a corregir esas otras cosas. Ahora, Juan, fíjate que...
Juan (1:03:47)
Sí, sí.
Douglas (1:03:49)
A mí me gustaría agregar un consejo más de cómo evitar que la deuda técnica se genere y es algo que también hacemos, que yo lo he hecho por años de por mí propia cuenta, pero eso es algo que hacemos como práctica aquí en field que antes era TenOp donde yo trabajo.
Y es que cuando se lanza un producto nuevo, ese producto nuevo que vos esperas que nace con las últimas versiones y que nace con las mejores prácticas y con mejor arquitectura, eso es lo que esperas, ¿no? La mayoría de las veces no siempre así. decías que nazca, bonito, desde el momento de su lanzamiento crear algo que nosotros le llamamos Post Launch Task.
que son tareas después de lanzar el producto. ¿A qué voy con esto? O para dar algún par de ejemplos. Son tareas muchas veces de que al momento de que estás lanzando, vos ya sabes qué se va tener que hacer. Por ejemplo, un proyecto reciente lo migramos de un hosting en específico o lo migramos a AWS. ¿Verdad?
Y entonces, el repositorio funciona por diferentes branches y el main branch publica producción. Pero ahorita que publicamos IWS, se creó un branch temporal que publica IWS que se llama main-aws. Entonces, una vez que ya lanzamos IWS, en el momento que lanzás, publicamos del branch main-aws.
Pero ya sabemos que luego eso se tiene que corregir y tiene que apuntar al branch main. Entonces, inmediatamente cuando se presenta lo que llamamos el launch plan, que es el plan de cómo se va a ejecutar el cambio o el lanzamiento, ese incluye esas tareas que se van a hacer luego del lanzamiento, que puede ser minutos después del lanzamiento o pueden ser días o semanas después del lanzamiento, y que incluye corregir los branches y apuntarlos al lugar necesario.
Y a veces incluye retirar los servidores anteriores, por ejemplo, y se pone la tarea dos semanas después por si llegara a algún inconveniente y todavía hay que hacer rollback, dos semanas después retirar los servidores anteriores. Y así surgen ese montón de tareas post lanzamiento que nosotros la sabemos.
que a veces las comentamos en el Daily o las comentamos en la reunión donde lo estamos planificando, pero si no se ponen por escrito, si no se les da un estimado y si no se asignan, la mayoría de ellas no van a ocurrir, generando lo que estamos hablando, deuda técnica, ¿verdad? Entonces tomar ese tiempo al momento de planificar el lanzamiento, una migración o cualquier tarea grande.
Juan (1:06:30)
Sí.
Correcto.
Douglas (1:06:48)
agregar esas post-launch tasks o tareas después del lanzamiento, identificarlas, darles estimados y asignarlas, hacerlo en ese momento, eso Juan es otra de las cosas que nos ayuda exagerado a nosotros para prevenir que se genere una nueva deuda técnica o que tal vez siga creciendo la deuda técnica existente. Y yo creo que eso realmente tiene un impacto grande.
cuando se pone en práctica de manera apropiada.
Juan (1:07:21)
Es curioso porque siempre que se lanza producción o se lanza un nuevo servidor, siempre tenemos como variables que la estamos utilizando de manera temporal o código que lo necesitamos solo para ese momento y luego hay que limpiarlo. Recuerdo algo reciente donde nosotros, mi equipo trabajo, empezamos a poner un montón de logs, pero
Si bien sabes, tenemos diferentes niveles de locks y bueno para los que no sepan es una muy buena costumbre tener diferentes niveles de locks donde el nivel más bajo te muestra todo lo que pasa en la aplicación y luego hay un nivel intermedio donde solo errores y así. Nosotros teníamos activado el nivel más bajo que para nosotros es el nivel trace y ahí muestra todo. No, perdón.
perdón, perdón, es el nivel info, ese sí muestra todo. Bien, entonces la idea era tener eso un tiempo muy corto en producción mientras identificábamos algo que estaba sucediendo.
era un bug que era muy difícil de identificar porque sucedía muy esporádicamente y ni siquiera sabíamos por qué ni cuándo sucedía, entonces pues ni modo, toca recolectar información así que activamos todo. Pero sí me llama la atención porque de nuevo son de ese tipo de tareas que tienes que hacer después, ok ya corregimos el error, ya sabemos qué pasa, entonces desactivar esos niveles de logs y que a veces se puede, uno lo puede olvidar.
y pareciera algo inofensivo decir bueno pues sólo estamos logeando pero eso es algo que va hacia estuary todos los logs van hacia estuary y pues eso es algo que se está pagando y se puede utilizar para otras cosas pero que me llama la atención porque en tu caso ya lo tienen por escrito y eso me parece genial porque bueno así como yo, yo olvido mucho muchas cosas
Douglas (1:09:21)
Sí,
Juan (1:09:35)
entonces tenerlo por escrito es muy bueno de hecho algo que he empezado a hacer Douglas así por hablando de todo un poco es que ahora tengo mi propio como mi propio sistema de tickets en mi pc en mi local porque me di cuenta que me da pereza entrar a Gira entonces tengo los tickets de Gira y luego tengo mi propio ticket ya pero son tickets que yo defino no o sea mucho más granulares y más específicos y los escribo
mi manera entonces porque no a veces se me olvida y a veces son tickets que no no representan un ticket de gira sino como mañana responderle a tal persona y esa es mi tarea entonces si empezaba a hacer eso porque de no escribirlo es la mejor manera bien
Douglas (1:10:24)
Sí, sí, y aplica, perdón,
aplica a esto que estamos diciendo, ¿no? De evitar la deuda técnica. Lo que está escrito, la posibilidad de que ocurra es alta, lo que quedó en mi mente, la posibilidad de que ocurra es baja o a veces nula.
Juan (1:10:31)
Sí.
Sí, sí, Y tener la documentación correcta, todo tiene que estar por escrito. Algo que solemos hacer es tener el readme por microservicio. Cada microservicio tiene su readme y a veces es difícil tener actualizado el readme porque los servicios van evolucionando, se quitan, se les ponen cosas, entonces es necesario. Sí. ⁓
Douglas (1:11:04)
Y eso es una deuda técnica muchas veces, Juan, actualizar
documentación, eso es una gran deuda técnica. Y es ahí donde también los procesos, lo hablábamos en episodios anteriores, donde un proceso debería definir un pull request incluir.
actualización a la documentación de ser necesario y eso va de la mano con lo que vos decías anteriormente. estoy haciendo, si ya estoy trabajando en la funcionalidad de login, ahí aprovecho a corregir los diferentes bugs o situaciones que están ahí, eso va de la mano con todo. Pero la documentación realmente yo creo que es de las más complicadas de mantener.
Juan (1:11:41)
y da pereza.
Douglas (1:11:42)
Y
y taretas pequeñas como esas, cada cambio pequeño lo agregando, eso ayuda un montón.
Juan (1:11:48)
De hecho, en uno de los primeros trabajos que tenía, era necesario que cuando se hacía un cambio al código, dentro del código incluíamos el número de ticket, el número de issue.
en la documentación. Entonces era muy curioso porque luego mirabas ciertas funciones o clases dentro del código que tenían una documentación grandísima de diferentes tickets porque tal vez eran partes más críticas y requerían que estuviéramos cambiando. Pero es algo muy bueno, es una actividad muy buena. De nuevo, hay muchas maneras de ir controlando esto. Nosotros vamos dando nuestras experiencias y los
que creemos mejores. Pero definitivamente hay más motivos por los que da sucede la debuda técnica y hay otras formas también de cómo mitigarla. La idea de esta plática era pues tratar de darles una pauta de cómo iniciar a contemplar esto en su flujo y en el ciclo de vida de la aplicación. Y por eso, bueno, me gustaría como para terminar Douglas, no sé si quisieras tal vez
repetir uno de tus consejos o si tenés un consejo que consideras bueno este me parece que es el más el más importante o el más digamos que tiene más el mayor peso antes de tirarte la pelota para no no tirarte tan tan en frío me gustaría dar uno de mi parte y me gustaría cómo como decirles que contagien a su equipo de trabajo con
esta mentalidad de mitigar la deuda técnica. Sé que no suena como algo tan grande o como algo muy, algo que se pueda seguir tan fácil, pero créanme que realmente es la deuda técnica, como ya estamos hablando, muchas veces no viene o la gran mayoría de las veces no viene por la falta de conocimiento técnico o porque somos malos trabajadores o malos desarrolladores, no viene por ese
Muchas veces por la cultura que hay dentro de la empresa o por cómo está el ciclo de la aplicación que están lanzando nuevos features para atraer más usuarios, etcétera.
Entonces, pero si logramos contagiar a nuestros compañeros de adquirir esta mentalidad y tenerlo más presente, yo creo que al final del día se va generando algo más, un mantenimiento más fácil. Con lo que nos has comentado Douglas, yo creo que en tu equipo de trabajo sí tienen esta cultura mucho más arraigada y mucho más estructurada. Entonces, yo creo que muchos deberíamos como aspirar a tener algo
como eso en nuestro equipo de trabajo. por eso para mí yo creo que eso es uno de los pilares para tener algo, una deuda técnica mínima. Pero bueno, no sé si en tu caso quisieras tal, o si vale repetir algunos que ya diste o no sé si tienes otro.
Douglas (1:15:06)
Fete, sí tengo un consejo y es de que lo tomemos con calma. Ese es el consejo. No importa cuál sea tu carácter, no importa cuál sea la forma en que afrontas las diferentes tareas, tomémoslo con calma. Entendamos que la deuda técnica es inevitable. Aquí hay un montón de puntos y cosas que no hemos mencionado, cuánto influye el negocio.
en la deuda técnica, cuánto influyen las prioridades que nos definimos nosotros, cuánto influye lo que hemos heredado. Hay tantas cosas que no hemos profundizado porque el tema realmente tiene bastante de qué hablar, pero tomémoslo con calma. Que nuestra misión sea enfocarnos en minimizarla y si por algún lapso de tiempo la logramos erradicar donde estamos, bueno.
sepamos que no va a ser para siempre. Desearía que sí fuera para siempre la solución, pero lo más seguro es que no sea así. Si tu carácter es que sos alguien perfeccionista y te gusta ver todo bien hecho, todo bien estructurado y todo resuelto en tiempo y forma, tomémoslo con calma, ¿verdad? Porque ahí va a estar siempre y busquemos atacar lo que podamos atacar una cosa a la vez. Si somos de las personas que procrastinamos,
la mayoría, como que lo principal que genera esa actitud de procrastinación es que pensamos en todo lo que hay que hacer y nos abruma la cantidad de cosas que hay que hacer y eso me lleva a la actitud, sin darme cuenta, de procrastinar porque me siento abrumado mentalmente de todo lo que hay que hacer. Entonces aplique el consejo otra vez, tomémoslo con calma, identifiquemos una tarea, identifiquemos... ⁓
Tomen los consejos que dimos aquí, tomen algunos de los consejos que dimos y implementenlo acorde a las necesidades de su equipo de trabajo o su empresa, pero llevémoslo con calma y esa es la manera en que lo vamos a resolver. Aclarando que no digo calma de dejar lo que ocurra, sino calma para que afrontemos la situación con mente fría.
y podamos idear un plan estratégico adecuado para mitigarla y para evitar que siga creciendo.
Juan (1:17:34)
Qué gran consejo Douglas, definitivamente es un gran consejo. si tratamos de hacer todo al mismo tiempo, no vamos a hacer nada al final. Me gusta, me gusta tu consejo y ojalá que la gente también lo aplique. Bien.
Me gustaría entonces darte las gracias Dulas, gracias a las personas que están con nosotros hasta este momento del video. Muchas gracias a nuestros seguidores, los que le dan like, a los que le dan follow. Si les agradeceríamos que le den like también a este video, que comenten, ⁓ comenten nos cómo aplican ustedes en su trabajo, cómo evitan la deuda técnica o si comenten nos si tienen una deuda técnica que es imposible de pagar.
Entonces ahí lo pueden decir y vamos a compartir nosotros nuestras también experiencias.
Douglas (1:18:28)
Y Juan, si
quien nos ve nos escucha, este es el primer episodio que llegan a ver de Deben Ops, tienen una duda técnica grande, vayan a escuchar los anteriores para que le puedan sacar más valor a los diferentes temas también que hemos conversado antes.
Juan (1:18:44)
Correcto, sí, tienen una deuda técnica con nosotros. Sí, definitivamente. Pero bueno, he disfrutado mucho la plática Douglas, muchas gracias por acompañarme en esto y de nuevo, muchas gracias a los que nos ven, ha sido un placer y bueno, recuerden, nos vemos a la próxima. Bye.
Douglas (1:18:53)
igual.