Muy recomendable artículo de Zeynep Tufecki en The New York Times, «The shameful open secret behind Southwest’s failure«, que debería ser de lectura obligada para todos esos gestores que deciden posponer la actualización de sus sistemas por cuestiones de rentabilidad, y que incurren en la llamada deuda técnica, un concepto que nos lleva a mantener sistemas desfasados y a intentar arreglar poniendo parches tecnologías que deberían haber sido jubiladas hace mucho tiempo.
El concepto de deuda técnica no es en absoluto extraño a la industria de las aerolíneas: ya hablamos de ello en junio de 2017 con el caso de British Airways, que experimentó una catastrófica caída de sus sistemas que produjo que aproximadamente 75,000 pasajeros en los dos aeropuertos más importantes de Londres viesen sus vuelos cancelados o retrasados durante horas, no pudiesen despegar ni recuperar su equipaje, y permaneciesen haciendo cola durante horas a la espera de algún tipo de explicación.
El caso de Southwest Airlines es similar: un desastre tecnológico debido a software anticuado que impedía asignar tripulaciones a los vuelos y que, tras la cancelación de muchos vuelos debido a una tormenta, impidió a la compañía retomar su actividad y la forzó a cancelar más de quince mil vuelos durante la semana siguiente a la tormenta, impactando a más de un millón de pasajeros. El caso tiene numerosos agravantes: un problema sobre el que los trabajadores llevaban muchísimo tiempo advirtiendo, un CEO con un sueldo multimillonario y una compañía que prefirió priorizar inversiones financieras para hacer parecer que era una compañía sólida frente a la indispensable actualización de sus sistemas o a detener la progresiva rebaja de los sueldos del personal. La compañía recibió cincuenta mil millones de dólares del gobierno para paliar sus pérdidas por la menor actividad debida a la pandemia, pero tomó la decisión de invertir cuarenta y cinco mil de esos millones de dólares en recomprar sus propias acciones para reducir así la caída de su cotización.
Al final, pasa lo que pasa: tu compañía se convierte en un castillo de naipes apoyado sobre una base de cartas cada vez más débiles. Y ante una situación irregular debida a una tormenta, el torturado software colapsa y convierte el asignar tripulaciones a vuelos en una tarea imposible. Nada sorprendente considerando que durante años, los trabajadores se quejaban de problemas cuando intentaban llevar a cabo esa misma actividad de manera rutinaria, y simplemente recurrían a hacer las cosas por teléfono cuando se encontraban con que el software fallaba. Pero cuando la rutina deja de serlo debido a cualquier circunstancia excepcional, la capacidad de seguir haciendo las cosas de esa manera desaparece porque los problemas se acumulan, y se vuelven imposibles de solventar mediante excepciones. Un efecto paradójico: la aerolínea tiene todos los recursos necesarios para llevar a cabo su actividad, pero un problema le impide coordinar esos recursos.
Detrás de estos problemas siempre hay personas concretas: en este caso, un CEO multi-laureado que decidió asignar las prioridades de manera ya no errónea, sino gravemente irresponsable. Cuando, en octubre del 2021, la compañía tuvo otra crisis de cancelaciones, este mismo directivo hizo declaraciones en las que afirmaba que «su tecnología era maravillosa«, aunque algunas partes pudiesen necesitar ciertas mejoras. Aparentemente, esas mejoras nunca llegaron a llevarse a cabo. La comunidad de directivos piensa que este CEO es poco menos que un genio, lo que indica cómo de generalizado puede llegar a estar un problema así.
En el fondo, es lo que ocurre cuando los incentivos corporativos se desalinean de la estrategia: un directivo que trata, a costa de lo que sea, de preservar su sueldo elevado y su bonus calculado en función de los resultados del trimestre o del año, y que, por tanto, no pone ningún esfuerzo en asegurar que la actividad de la compañía sea sostenible a largo plazo. El largo plazo no está incentivado. Conozco, desgraciadamente, infinidad de casos como ese, y sin duda, los seguiremos viendo, porque nadie aprende en cabeza ajena y el caso de Southwest Airlines, por muy de libro de texto que sea, será difícil que haga que otros directivos de otras compañías e industrias decidan cambiar sus mal asignadas prioridades.
A lo mejor, escuchar a las personas responsables de los sistemas que hacen que las compañías funcionen y atender a sus demandas no es una mala idea.
ACTUALIZACIÓN (18/12/2023): Southwest ha sido condenada a pagar una multa de 140 millones de dólares, además de las devoluciones de los billetes a los pasajeros afectados, por su caída durante las navidades de 2022. Se considera una sanción relativamente simbólica, dado que tan solo una cuarta parte será una multa como tal, el resto serán indemnizaciones que correspondían a los pasajeros en cualquier caso.
This article is also available in English on my Medium page, «How technical debt can cripple a company when the perfect storm hits»
En la consultoría de software en España este es un problema muy antiguo. Se incentiva al personal de ventas para vender proyectos independientemente de si el desarrollo de esos proyectos es rentable o incluso si son realizables.
Luego los culpables son los desarrolladores, pero mientras tanto se han cobrado los bonus de esas ventas.
He participado como infotrmático en las consecuencias de la gran decisión. sustituir el Hard o Soft, (generalmente los dos), que ha quedado anticuado y obsoleto por otro moderno. Una de las decisiones mas delicadas y difíciles que hay que tomar periódicamente.
Habitualmente, se compra un Hard moderno para soportar una aplicación nueva, que el Hard antiguo no no soporta, con la intención de ir cambiando poco a poco todas las aplicaciones del equipo antiguo por otras nuevas en el nuevo equipo. Por su puesto, este proceso dura años. y en ese momento para tener integrados todos los datos se generan una serie de programas de interfase que actualizan los datos en ambos sistemas, por ejemplo en la Base de Datos y la «Nube» con lo cual aparte de todas las aplicaciones que tuvieras, aparecen cientos de aplicaciones cuya misión es preservar la integridad de los datos en la medida de lo posible de modo que cuando una aplicación cambien los datos en la nube, la interfase los cambie igual en la Base de Datos y viceversa.
En total aumentas geométricamente las posibilidades de bugs, y fallos.
Sobre el papel el proceso de migración iba a ser rápido pero la experiencia indica que es falso por varios motivos:
Económico.- Desarrollar una aplicación nueva para sustituir una vieja no mejora la mecanización de la empresa en el corto plazo y tiene un gasto tremendo. que en épocas de crísis, como la actual, (que son las mas), encuentra muchas razones para «aplazar» el proceso.
Seguridad.- Nada asegura que la nueva aplicación vaya a funcionar mejor que la antigua que ha sido ya testada por el uso largo tiempo. El tradicional «Si funciona, no lo toques» tiene esta causa una triste experiencia que tenemos todos los informáticos
Se suele destinar a ello un equipo de informáticos, que como no tiene una clara fecha de entrega, puesto que el sistema mixto funciona, por lo que frecuentemente se echa mano de ellos, con el fin de sacar adelante una urgencia real de la compañía de asuntos de emergencia a campañas de Marketing que precisan un soporte informático. Con lo que la migración avanza a trompicones y generalmente con mala comunicación entre quienes lo hacían hace 3 años y los quienes lo hacen hoy.
Consecuencia el proceso de migración no se acaba nunca, siempre quedan flecos por migrar.
A pesar de todo, estoy con la opinión de E Dans y la actualización informática es un toro que no queda mas remedio que tomar por los cuernos, y que pase lo que pase.
Que buena explicación. Por cierto, un poco off topic: hay un sector donde los incentivos a corto plazo son el gran problema de muchas más personas que en las aerolíneas: la política. Ganar elecciones hace que las decisiones políticas no contemplen la gran mayoría de cosas que deberían para la mejora de un país, y que requieren pensar a largo plazo.
Estoy totalmente de acuerdo contigo en que el software, por muchas pruebas que hagas, nunca está exento de tener Bugs. Eso lo sabemos todos los que hemos trabajado en software alguna vez, pero unas pruebas bien realizadas ayudan mucho a la minimización de esos Bugs.
La deuda técnica implica un software mal concebido y mal desarrollado lo cual implica el empleo de más tiempo en el futuro en el mantenimiento y evolución del software. Por eso se recomienda realizar evoluciones pequeñas, aunque se encuadren dentro de evoluciones mayores, y una refactorizacion continua del software.
El uso de la refactorizacion continua, junto a otras técnicas de desarrollo como la creación de pruebas unitarias, integración continua o el manejo de herramientas de control de versiones son una gran ayuda para crear un buen software. Y el problema de muchos desarrollos es que no se emplean adecuadamente estás técnicas.
Mencionas, por ejemplo, el paso de pesetas a euros. Eso no tiene nada que ver con la deuda técnica. Uno de los problemas de los desarrolladores es pensar en el futuro y eso es incorrecto. Sólo hay que pensar en el presente y los requisitos actuales porque el futuro es incierto y no se debe jugar a adivinador ya que eso sí implica mucha deuda técnica. Si actúas como adivinador acertarás, por ejemplo, en un diez por ciento de las funcionalidades futuras. Y en el noventa por ciento de los casos habrás introducido código que nunca se va a utilizar con varias consecuencias de las que destaco dos: retardo en tu trabajo porque estás añadiendo cosas innecesarias y código inservible dentro de tu código. Y eso si que es deuda técnica.
Me he debido expresar mal. No se trata de ser adivinador, Estoy de acuerdo, (a medias), con lo que dices, ·Uno de los problemas de los desarrolladores es pensar en el futuro y eso es incorrecto. Sólo hay que pensar en el presente y los requisitos actuales porque el futuro es incierto y no se debe jugar a adivinador ya que eso sí implica mucha deuda técnica
Un programador debe programar exactamente lo que dicen los requerimientos técnicos y si algún punto no lo ve claro, solicitar que se lo aclaren a ser posible antes de escribir una línea de programa.
Otra cosa es el analista que no ha de adivinar, pero si averiguar cual va a ser el devenir de la companía y en la medida de lo posible dejar apuntada la futura ampliación de requisitos que pueden razonablemente producirse.
Esto suele resultar fácil en algún tipo de aplicaciones, por ejemplo una Contabilidad. A poco bien que la hagas acepta bastante bien los cambios de criterios contables, pero en otras como Nómina es dificilísino, pues basta que salga una norma en el BOE para que te veas negro para adaptar tu nómina a estos cambios legales. Suponte que el Gobierno, modifica la retención en función del número de hijos. lo mas probable es que tengas que añadir datos en la BA con lo que supone de cambio en muchas pantallas y listados y tendrás que modificar el módulo que calcula las retenciones
Este tipo de cosas son inevitables con el paso del tiempo, forman parte de la «vida» de una aplicación que la llevan a envejecer hasta el punto que un día hay que plantearse hacerla de nuevo, porque aquello es un colección de remiendos, que funciona en una máquina obsoleta .
Entiendo que cuando hablas de analista te refieres a la persona que sabe del negocio. La tendencia actual es llamarla «product owner» en metodologías ágiles. Esa persona tiene que estudiar como van las aplicaciones rivales e intentar anticiparse en la evolución del software buscando las mejores soluciones en el «que tiene que hacer mi software» pero sin meterse en el «como se hace el software» que es misión de los desarrolladores. Y son estos últimos los que meten en el software deuda técnica porque la deuda técnica tiene relación con como se hace el software y no «que hace el software». Más abajo intento explicar la relación que hay a la hora de desarrollar funcionalidades que no aportan valor al negocio y la deuda técnica.
El que sabe del negocio es el usuario. El analista es el que sabe preguntar al usuario, por qué hace lo que hace y lo trasforma en un flujo de información en forma de datos.
Son dos métodos de trabajo diferentes. Cuando hacer informática «a medida», no mitas lo que hacen otras aplicaciones similares, sino lo que hacen tus usuarios del Director General al último administrativo con papel y lápiz y lo digitalizas. Cuando haces «aplicaciones verticales», te enteras de como lo hacen en una empresa, buscas mejorar y generalizar el procedimiento, te informas de las virtudes y errores de la competencia y tratas de copiarlas unas y evitar otras.
Deuda técnica versus funcionalidad. La deuda técnica es un parámetro interno del software mientras que la funcionalidad es un aspecto externo al software. Un software puede cumplir perfectamente con los requisitos funcionales y estar cargado de deuda técnica. Los motivos de la deuda técnica pueden ser variados: inexperiencia, prisas por la entrega, cambios en los requisitos en medio del proyecto … Pero lo que va a producir está deuda técnica en el futuro son problemas de mantenimiento y en cambios en la funcionalidad.
Pero que un software falle en un momento determinado porque se ha utilizado de una forma diferente no implica necesariamente que tenga deuda técnica sino que no se han hecho las pruebas adecuadas y completas. Esto también ocurre cuando los tiempos de entrega apremian.
Quiero decir con todo esto que un software puede funcionar sin dar problemas y tener una deuda técnica elevada y al revés, puede no tener deuda técnica y funcionar erróneamente en ciertos momentos por falta de unas pruebas exhaustivas.
Un informático puede decir, hemos hecho 100.000 pruebas a este software y las ha pasado con éxito, Pero no puede decir este software no tiene bugs.
Pongo un caso evidente, la fechas siempre se habían guardado como AAMMDD. En la proximidad del año 2000 descubrimos que había un error, porque nuestros sistemas de ordenación, situaban la fecha 000101 como anterior a cualquier fecha guardada hasta entonces, Fue el error del año 2000. ¿Cuántas pruebas y en cuántas aplicaciones se habían hecho y nadie había caído en cuenta del problema? Estos son bugs, que siempre aparecerá alguno nuevo de tarde en tarde por mas que cuidado que pongas.
Deuda técnica, a mi juicio, es la obsolescencia de Hard y/o Soft, tener funcionando simultáneamente, ficheros clásicos, con Base de Datos, estar utilizando internamente para los caracteres la codificación EBDCIC y en la terminales la codificación ASCII, Guardar los importes económicos sin decimales, como la peseta y de repente te llegue una moneda con el euro con céntimos. Tener previsto solo un bit para guardar uno de los sexos y como ocurre ahora, haya que guardar media docena diferentes.
Es decir, cosas que se quedan obsoletas simple y sencillamente por el paso del tiempo.
Por otra parte indefectiblemente hay que ampliar las aplicaciones a nuevas opciones no previstas en el estudio inicial, algo que poco a poco envejece el sistema, pues al final es una colección de parches y remiendos que tiende a hacer aguas por todas partes.
Hablando del Rey de Roma, por la puerta asoma
Miles de personas varadas en aeropuertos de Filipinas por problema técnico
Que yo recuerde, todos los que andábamos en otras plataformas lo sabíamos pero como siempre agogueros nos llamaron lo s que adoraban al Dios IBM y su hijo el PC.
Clipper usaba 8 caracteres y no seis, pero claro la BIOS pensaba diferente y era esa BIOS y su reloj la que establecía la fecha y hora… La de los viejos Mac la veré antes de morir, no recuerdo si para los 30 o los 50.
Joder, que hasta bases de datos para equipos de 8 bits tenían 8 caracteres para la fecha si disponían de disquetera.
El Ayuntamiento de Barcelona acaba de jubilar su Mainframe (artículo en El Español) para usar otras plataformas… No es por nada, pero el último AS/400 tenía formato minitorre,
En todos los equipos que he trabajado, generalmente de IBM, el formato de la fecha y el orden del contenido día/mes/año definía el analista, y lo cierto es que por inercia las fechas las solíamos definir AAMMDD, no era requerimiento de IBM,
Otro tema importante, relacionado con lo que ya mencioné más arriba al hablar de «no adivinar el futuro» es «centrarse en lo que aporta valor al negocio» y dejar para más adelante lo menos importante ya que un desarrollo software se puede cancelar en cualquier momento. ¿Qué ocurre en muchos proyectos grandes? Primero echamos no sé cuántos meses creando unos requisitos gigantescos, después hacemos un diseño mastodóntico al que le dedicamos otros tantos meses y cuando nos ponemos a desarrollar empezamos por lo fácil independientemente de que valga para algo o no valga para nada. Y cuando nos ponemos con lo verdaderamente importante y que aporta valor al negocio tenemos miles de líneas de código inservibles y ya es imposible volver atrás. El resultado lo vemos día a día: aplicaciones gigantescas que son imposibles de modificar.
Y como efecto secundario, el cliente se da cuenta tarde de que no es lo que quiere y lo quiere modificar todo. ¿Qué hacemos en ese momento? Lo que le pasa a una gran cantidad de proyectos. Lo tiramos a la basura por inservible o lo ponemos en producción pero con tantos problemas que ya no tiene remedio. Y cuando se afronte un cambio cuesta horrores.
Concluyo: es muy necesario cambiar la mentalidad en la forma de desarrollar el software.
Después de varios comentarios en los que hablo por una parte del código y sus fallas y por otra de los requisitos y lo que hay que hacer en un desarrollo software voy a intentar hablar del «desperdicio».
Es necesario centrarse en lo que aporta valor al negocio. El resto lo podemos denominar desperdicios y todo eso es deuda técnica. Cuando desarrollo una funcionalidad y la dejo a medias, no aporta valor y queda ahí metiendo ruido. Cuando desarrollo una funcionalidad a futuro porque creo que me la van a pedir, no aporta valor y queda ahí metiendo ruido. Cuando desarrollamos funcionalidades que ya han sido escritas por otros en el mismo proyecto estamos metiendo desperdicios. Cuando desarrollamos sin pensar las cosas detenidamente probablemente metamos desperdicios. Metemos mucho desperdicio en nuestro software, unas veces intencionadamente y otras de forma involuntaria y eso es lo que se debe evitar.
Todos esos desperdicios son internos al código y al final provocan mucho retrabajo y la evolución del código se hace compleja. Por otra parte estos desperdicios también provocan Bugs difíciles de encontrar, lo cual nos impide desarrollar funcionalidades que aporten valor al producto. En fin, la bola de nieve crece y crece.
Y perdonar porque todo lo que he escrito hoy no está bien estructurado pero lo estoy escribiendo según me viene a la cabeza.
De todas formas lo de los aeropuertos es desquiciante. Me encantaría que tomásemos el modelo africano (Hablo de Guinea Ecuatorial y de Gabón) que la gente se sube al avión como quien se sube al bus.
– Se compra el ticket en la entrada del aeropuerto
– Pasas por seguridad
– Vuelas
Lo mismo hacemos aquí con el AVE y nadie se escandaliza. Sinceramente tenemos que hacernos mirar la deuda técnica, pero desde una perspectiva minimalista.
a) ¿Es necesaria tanta frusilería en el avión? Si el trayeco es de menos de 3 horas, pues sin auxiliares de vuelo. Si hay una emergencia, pues como cuando en un teatro dicen «¿hay un médico en la sala?»
b) ¿Hace falta tanta seguridad? Está archidemostrado que cuando alguien quiere secuestrar un avión, lo puede hacer perfectamente. Cuestión de sobornar a quien haga falta. La chorrada de pasar arcos está sobrevaloradísima. Ni te digo lo de los cortauñas, perfumes de más de 100ml que no sean del duty free, etc. etc.
c) ¿Existen rutas regulares? Pues la mayoría lo son. Una tripulación va y viene de Madrid y Barcelona varias veces y descansan. Si es Madrid – Sao Paulo, van un día, descansan 2 y vuelven el tercero. Otras dos tripulaciones hacen lo mismo en los días de descanso. Se asignan personas fijas a rutas fijas, listos
d) ¿Un pasajero da problemas? Se notifica a la compañía que el del asiento 16B ha incomodado a todos y a la lista negra, nunca más volará con esta aerolínea. Te sacas de encima a los terribles. (No vale votar feo a un bebé que llora o sus padres… a veces son los primeros que votarían contra su niño, xD)
e) ¿Tiene que volar el avión vacío para no perder los slots? Un poquito de por favor, ¿no?
Si nos replanteamos toda una serie de protocolos, de forma más seria que yo, resultará que nuestras aplicaciones podrían reflejar procesos simplificados. APIs interoperables por ley y hacer las cosas con sensatez.
¿No os parece extraño que el AVE de Madrid a Barcelona tarde 3 horas y media y en avión tardes lo mismo por tener que llegar tan supertemprano al aeropuerto por la seguridad + ir hasta el gate + cambios de puertas de última hora?
Y no nos olvidemos de la Adminstracion Pública. Creo que ya he dicho alguna vez que, en España, sólo Hacienda tiene una informática del s.XXI mientras el resto sigue anclada en los años ochenta.
Y pasa lo que pasa, que llega el momento de estrés -pandemia- y toda la administración se va al garete porque informáticamente no es capaz de procesar el nuevo trabajo. Y así se hunde miserablemente la gestión telemática de Seguridad Social, Sanidad, Justicia, SEPE, etc.
Como muestra, este pequeño ejemplo que justo acabo de leer: cómo pagar, o no, en la web de Cita Previa e-DNI.
https://twitter.com/rodpedja/status/1609664076237492225?s=61&t=41n3nfLUhXEZpIkBukqr-w
El mantenimiento no se inaugura.
El mismo problema se ve en cualquier empresa que necesite mantenimiento básico a gran escala: es algo que siempre puede dejarse para más adelante y ahorrar costes hoy, o priorizar cosas más brillantes. Hasta que, por supuesto, por ser básico acaba erosionando las bases fundamentales y todo colapsa sin remedio.
Para desastre tecnológico, el Patronato de la Alhambra. Tienes que ir con reserva de plaza, pagada, Hasta aquí de acuerdo, pero te exigen que vayas una hora antes de la hora de entrada, «para validar la entrada». que te han mandado y luego, no se por que razón, tienes que enseñar TRES VECES tu DNI a distintos seguratas que hay en la puerta que te lo leen con un scanner.
Aquí depende mucho la eficacia y tino de CTO a la hora de seleccionar herramientas.
Conozco una gran empresa que tuvo el acierto de desarrollar todas las extraciones de datos en python y java contra Oracle, y desupés migró esta última a PostGres. El caso es que esas herramientas están hoy en día muy en boga, por lo que aquella elección hace 20 años resultó todo un acierto.
En cambio otros diseñaron sus aplicaciones críticas con sistemas muerto, y han tenido que rehacer todo el trabajo varias veces porque siempre eligieron mal la herramienta.
Fuera del estado español está mucho mejor valorado el CTO, ya que sus errores son dramas
Otra empresa con deuda técnica es UPS: hace poco tuve que subir documentos a su web desde mi página de usuario y no funcionaba. ¿La solución de soporte al cliente, luego de semanas de reclamo?: que la envíe por fax (a un número que no funcionaba) o que la lleve personalmente, en papel, a una oficina fuera de Barcelona.
Ellos no solo tienen SW que no funciona, sino que su servicio al cliente está hecho para bloquear y frustrar al cliente para que este deje de reclamar.
«La compañía tomó la decisión de invertir cuarenta y cinco mil de esos millones de dólares en recomprar sus propias acciones para reducir así la caída de su cotización».
Y si no lo hace, tienen una obra de informática abierta sin fecha de finalización y accionistas que abandonan ya el barco por falta de dividendos y riesgos de pérdida a corto plazo.
Las corporaciones que cotizan en Bolsa dependen mucho más de los accionistas que de los clientes.