- 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?
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?