Hablemos de la Deuda Tecnica

Ahora tenemos algo similar en un proyecto, hay que crear sucursales y tengo que hacer la wea a mano, una soberana paja.

Generalmente cuando nos pasa eso es porque el cliente no supo definir bien el requerimiento y se deja para el final, cuando ya se dan cuenta de que era necesario redondear la app al principio

Creo que tb me ha tocado hacer esos mega inserts en bases con info de texto plano. Lo que hacia era abrir excel, separar por filas y columnas, y luego en otra hoja hacia una formula del tipo
=concat(a1,a2,a3,a4) hasta que salia una frase para sql.

¿Por qué abro un tema y le doy color? Porque recién hace dos semanas me enteré de que había un par de palabras para esto. Es como cuando los alemanes le dan palabras a cosas como "pegarse en el dedo meñique con la esquina de un mueble, saltar de dolor y enterrarte un lego en el otro pie, entonces te vas de hocico al suelo" y eso se llamaría "snashbruttenmorhn".

Zuljin dijo:

Las tarjetas bip con su código y todo eso se deben dar de alta. Y si, nos mandaban un archivo de texto plano con la mansa cachada de códigos, nosotros los transformábamos en inserts en la base de datos y chum padentro.

Haz clic para expandir...

Oie esa wea la arregle hace como 6 años 😡

Zuljin dijo:

¿Por qué abro un tema y le doy color? Porque recién hace dos semanas me enteré de que había un par de palabras para esto. Es como cuando los alemanes le dan palabras a cosas como "pegarse en el dedo meñique con la esquina de un mueble, saltar de dolor y enterrarte un lego en el otro pie, entonces te vas de hocico al suelo" y eso se llamaría "snashbruttenmorhn".

Haz clic para expandir...

Se llama a la Chilean wey XD

Y no digo nada más porque después se ponen sensibles

La deuda tecnica esta directamente relacionado al conformismo y el tratar de hacer lo minimo, creo que muy pocas veces a recursos.

en TODOS los sistemas hay deuda técnica, y es un concepto harto viejo, pero en general es todo aquello que se hizo apurado. Con el tiempo sin embargo, todo se va haciendo deuda técnica pq lo programado hace 2 años atrás cuando lo miramos con los ojos de lo que ahora sabemos está horrible y se convierte por si solo en deuda técnica.

De ahí que hacer sistemas modulares y los famosos microservicios han tenido tanto arrastre, pq es mucho más fácil trabajar en un código pequeño que sólo hace una cosa a tener que mantener un monolítico con dependencias por todos lados, sin embargo, eso introduce también varios niveles de dificultad adicionales.

Saludos.

Yo creo que el problema de la deuda técnica no es tanto su existencia que es inevitable, sino más bien el acostumbrarse en el tiempo y el arrastre de la huea.

Zuljin dijo:

Yo creo que el problema de la deuda técnica no es tanto su existencia que es inevitable, sino más bien el acostumbrarse en el tiempo y el arrastre de la huea.

Haz clic para expandir...

Y que generalmente no le tomen el peso

Zuljin dijo:

Yo creo que el problema de la deuda técnica no es tanto su existencia que es inevitable, sino más bien el acostumbrarse en el tiempo y el arrastre de la huea.

Haz clic para expandir...

Es un tema de voluntad y orden más que nada, a la gente le gusta nadar en la mierda que le llegue al cuello, especial en TI, como los tienen que llamar a cada rato para levantar los sistemas con palitos, se sienten importantes, como que justifican las lucas con el exceso de pega por que no hacen las cosas bien.

Hace unos años me tocó auditar una empresa que contaba con Sap business y unos addon de HHRR y Punto de venta.
estos addon funcionaban, pero como satélites y al final la información se terminaba procesando en Excel y después se cargaba al Sap.

No querían cambiar el sistema ni reconfigurar por todo el tiempo, esfuerzo y dinero invertido y aunque sabían que no era ni remotamente óptimo a ellos les funcionaba dicha figura.

En realidad siempre hay un poco de deuda técnica en todos los proyectos que pasaron por una etapa de prototipo o MVP. Si pagas esa deuda en esa etapa se demora el doble y son iteraciones que pueden ser efímeras.

La cosa se pone seria cuando algún wea avisa como gran logro que ya tiene clientes o usuarios finales usando el prototipo. Y ahí cagaste, tienes que parchar algo que era una maqueta. Pero bueno, en esa parte, si definiste bien el contrato de interfaz, podrías sustituor el prototipo por algo mejorcito cada vez. Sólo ser disciplinado y no añadirle nada al protitpo directamente. Si te dicen que es urgente, sólo dices "estamos en eso".

Pero hay otras deudas técnicas. Cuando le pusiste pantalón largo al prototipo no hiciste la suite de tests, tienes que hacerla pero el wea te sigue pidiendo features, porque un cliente dijo que le gustaría que además tuviera un slideshow de gatitos.

No has hecho la documentación completa, y además no sabes dónde hacerla porque tienes una parte en el código mismo, otra en Postman, otra en Doxygen. La organización no tiene una política sobre dónde y cómo documentar, porque la oranización misma tiene deuda técnica.

El manejo devops también tiene deuda, porque el prototipo lo deployaste a mano. A lo mejor usando fabric o capistrano, pero fue manual. La deuda técnica abarca entonces los pipelines de integración continua y deploys gatillados.

Y durante todo el proceso, o todo el ciclo de vida del software, siempre te mantienes refactorizando, pero cada vez que lo haces el módulo de código más eficiente y refactorizado le sube la vara a los demás, y te endeudas con la necesidad de refactorizarlos.

¿Cuándo es un problema profundo? Cuando el sistema es una mole tan peluda de refactorizar que ya no se puede ajustar a las buenas prácticas. Muchos dicen "es más barato hacerlo de cero". Un par de ocurrentes mandan a hacer la versión 2.0, pero como ya no se sabe el contrato de interfaz del original no saben qué mierda debe hacer el nuevo prototipo. Pero es bonito, y el wea ya tiene clientes finales usándolo.