Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.868
El otro día estaba en una presentación de Nube cuando hablaron de Deuda Técnica en los sistemas.

La Deuda Técnica se refiere a cuando un sistema está incompleto ya sea porque no hicieron una funcionalidad o esa funcionalidad no funciona, pero para que siga funcionando al final otro equipo tiene que ingeniárselas con otros métodos para suplir esa falencia. Cuando oí el concepto sentí que todas esas rabias que había pasado tenían un nombre: LA PUTA DEUDA TÉCNICA.


En el Transantiago estábamos llenos de Deuda Técnica. Diría que los sistemas eran un 30% software y un 70% amarrados con alambre a.k.a. Deuda Técnica.

Por ejemplo, nos informaban que se crean nuevas estaciones de Metro. ¿Ustedes creen que teníamos un módulo especial para darlo de alta y dejarlo bien configurado? Nop, a punta de instrucciones SQL derecho a la base de datos.
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.

Y así mil hueas que el equipo de sistemas y operaciones teníamos que hacer a mano porque la funcionalidad o no estaba o funcionaba mal, y nunca era prioridad que crearan la funcionalidad o la areglaran porque "pah que, si ustedes ya lo están haciendo".
Lo más triste es que cuando creaban una nueva funcionalidad no era raro que saliera mala y de nuevo el equipo de sistemas y operaciones teníamos que armar algo con alambres para que esa nueva feature ofrecida al cliente funcionase. Así que se sumaba una piedra más a la Deuda Técnica. Los jefes y los clientes ya estaban acostumbrados a que si la nueva característica no funcionaba a la primera no importaba: esperaban a que lo ajustara la gente de sistemas y listo.

Otro ejemplo es vivir parchando un sistema legacy eternamente porque es más rápido que hacer el proyecto de migración.


¿Ustedes tienen historias tristes de Deudas Técnicas?
 

mmirandap

Gold Member
Se incorporó
1 Septiembre 2006
Mensajes
2.466
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 :risas
 
Upvote 0

ricm

Se incorporó
28 Agosto 2005
Mensajes
7.571
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.
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.868
¿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".
 
Upvote 0

ranamaldita

mueranse
Se incorporó
24 Junio 2003
Mensajes
4.522
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.

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


Not really, hace lo mismo pero automatico y valida :zippy
 
Upvote 0

Harima

Pegao al tarro
Se incorporó
15 Mayo 2008
Mensajes
3.956
¿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".

Se llama a la Chilean wey XD

Y no digo nada más porque después se ponen sensibles :amocapa9
 
Upvote 0

ranamaldita

mueranse
Se incorporó
24 Junio 2003
Mensajes
4.522
La deuda tecnica esta directamente relacionado al conformismo y el tratar de hacer lo minimo, creo que muy pocas veces a recursos.
 
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.591
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.
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.868
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.
 
Última modificación:
Upvote 0

Harima

Pegao al tarro
Se incorporó
15 Mayo 2008
Mensajes
3.956
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.
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.
 
Upvote 0

Aldebaran®

OC/***/MDBX user
Se incorporó
2 Junio 2009
Mensajes
208
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.
 
Upvote 0

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
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.
 
Última modificación:
Upvote 0
Subir