El concepto de deuda técnica es un eufemismo acuñado originalmente por el desarrollador norteamericano Ward Cunningham y utilizado para entender las consecuencias de una falta de atención al desarrollo de software o al despliegue de hardware, reflejado en forma de falta de actualización, mal mantenimiento, errores no subsanados, deficiente control de versiones, problemas de escalabilidad, o incorporación desordenada de nuevas funcionalidades.
En muchas organizaciones, el concepto de deuda técnica tiene su reflejo en la persistencia de desarrollos de software anticuados y no migrados a tecnologías más eficientes, los llamados sistemas heredados o legacy systems. La deuda técnica se contrae cuando determinadas tareas necesarias para asegurar la funcionalidad o la escalabilidad de los sistemas son pospuestas por razones habitualmente presupuestarias, por una deficiente asignación de prioridades, por una falta de sensibilidad de los directivos con la tecnología o por razones de otros tipos, y se acumula en forma de interés, que se acumula incrementando el coste de subsanar el problema. En no pocos casos, el importe de la deuda técnica llega a ser incalculable, y se refleja en la imposibilidad de incorporar funcionalidades consideradas críticas para el funcionamiento del negocio o incluso en la disrupción del mismo.
El pasado 27 de mayo, British Airways 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 fallo tiene lugar en el contexto de una polémica gestión del español Alex Cruz como CEO de IAG, que engloba también a compañías como Iberia, Vueling o Air Lingus, caracterizada por agresivas reducciones de costes y por la subcontratación progresiva de los sistemas de la compañía, una política bastante común dentro de la industria del transporte aéreo. Las declaraciones de Cruz el día de la caída no fueron consideradas por la mayoría como una gestión de crisis satisfactoria, y los posteriores intentos de explicar los problemas, apuntando a «un empleado de una subcontrata que apagó el interruptor que no debía«, tampoco parecen inspirar demasiada confianza.
La persistencia de sistemas legacy en la industria de las aerolíneas es sumamente elevada. La dependencia de sistemas de reservas con complejos esquemas de propiedad y la escasa atención a los aspectos relacionados con la tecnología ha redundado en que muchas aerolíneas acumulen una fortísima deuda técnica: sistemas anticuados que han evolucionado de manera descontrolada y a golpe de parche durante décadas, que conforman silos incompatibles entre distintas áreas, y que ignoran la funcionalidad de los sistemas modernos. Resulta perfectamente normal, por ejemplo, que los sistemas de reserva estén completamente desconectados de los de CRM y programas de fidelización, impidiendo de facto a la aerolínea una gestión proactiva de la satisfacción del cliente. Con el paso de los años, la persistencia de sistemas anticuados, cada vez más inestables, incapaces de escalar y de incorporar nuevas funcionalidades da lugar a una deuda técnica cada vez mayor, que termina redundando en problemas de todo tipo. Son las consecuencias de una cultura del tipo «si funciona no lo arregles» aplicada a un entorno de un dinamismo y cambio rapidísimo, en el que no mantenerse actualizado en sistemas considerados críticos para el negocio termina siempre por ser una mala decisión. Tras muchos años criticando a los tecnólogos porque eran «como las aves, que estaban siempre migrando», algunos empiezan ahora a caer en la cuenta de que tanta evolución no era un capricho, sino el resultado lógico de un entorno en constante avance.
Cuando veas sistemas anticuados, pantallas de fósforo verde en entorno carácter y tecnologías que recuerdan a las que veías hace décadas, piensa que no se trata simplemente de una empresa conservadora, que prefiera apostar por tecnologías muy probadas o que mantenga una política austera: es que estás tratando con una compañía que acumula una importante deuda técnica, y que eso la hace intrínsecamente más proclive a fallos que afecten a la continuidad de su negocio. Son, en esencia, compañías menos fiables, que han pospuesto a lo largo del tiempo modificaciones y actualizaciones críticas, y que han descuidado la incorporación de funcionalidades o lo han hecho a golpe de parches sucesivos. En las compañías con abundancia de sistemas legacy que acumulan una creciente deuda técnica no es fácil encontrar talento de desarrollo, porque no resultan retadoras ni interesantes para nadie: las tareas de mantenimiento predominan cada vez más sobre las de desarrollo, y las personas que se quedan en la compañía son, cada vez más, las que se especializan en lenguajes y funcionalidades que no se ven en otros sitios, constituyéndose en una especie de «sedimento» que pierde valor en el mercado y que tienden a hacer el problema todavía más complejo. En el contexto de unos negocios en los que la tecnología juega cada vez un papel más crítico, nada bueno puede salir de la deuda técnica, más allá de la comprobación de que los directivos de una compañía carecen de la sensibilidad suficiente como para apreciar su importancia. La subcontratación, en muchos casos, termina por convertirse en el último recurso de ahorro de costes, y en muchos casos tiende a empeorar el problema alejando las preocupaciones de unos directivos ya de por sí no muy conscientes de su importancia.
El fallo de British Airways es precisamente eso: un problema de deuda técnica impagada, con unos intereses acumulados durante años, que terminan por generar situaciones insostenibles. Y en ese estado, desgraciadamente, hay muchísimas compañías más, fruto de muchos años de negocios dirigidos por personas que no entendían ni querían entender la importancia de la tecnología. Ahora, la transformación digital se ha vuelto un factor crítico para la competitividad, y es complicado construirla sobre sistemas legacy completamente anticuados y parcheados hasta el límite. ¿Serías capaz de valorar la deuda técnica en tu compañía? ¿Las malas decisiones que han incurrido en que la tecnología se aleje cada vez más de la que define «el estado del arte» en tu industria? Las deudas, de un modo u otro, terminan por pagarse…
This post is also available in English in my Medium page, “What is technical debt, and why is British Airways up to its neck in it?»
¿Y los bancos? que todavía siguen buscando expertos en COBOL.
Ya ves, y eso precisamente cuando hace pocos días se murió Jean Sammet a los 89 años, la pionera que diseñó y popularizó COBOL, y que lo entendía como «una solución a corto plazo para la gestión de datos de negocio con formato»…
¡Vivir para ver!
No lo sabía, gracias por la información. Me ha traído a la cabeza la película Hidden Figures, donde se narra la introducción de los primeros ordenadores en la NASA, aunque en este caso el lenguaje era el Fortran. También a mi hermano mayor, que estudío programación en su tiempo, y se traía las tarjetas perforadas a casa.
Puedes trabajar en COBOL y no tener «deuda técnica». Un sistema en COBOL puede estar tan bien creado como un sistema en cualquiera de los lenguajes de programación más actuales. Y al revés, un sistema creado con un lenguaje moderno puede tener una «deuda técnica» altísima.
El concepto de deuda técnica no tiene demasiado que ver ni con la antigüedad del código, ni con el lenguaje de programación (aunque sea COBOL), ni con la interfaz de usuario o sus colores, ni con la subcontratación, ni con la reducción de costes, ni con que el sistema sea heredado («legacy») etc. Dicho de otra manera, podríamos coger a un equipo de programadores «in-house» hoy, ponerles a programar en los últimos lenguajes de programación, hacer interfaces de usuario web en colores, pagarles una pasta, y es muy probable que la versión 1.0 ya tuviera una deuda técnica considerable (lo veo todos los días en nuevos desarrollos). Si se trata de conectar sistemas «legacy» existen técnicas desde hace años para poner una capa o dos por encima y comunicarlos con otros sistemas. Y la escalabilidad es un problema diferente. En todo caso no es lo mismo la deuda técnica que la obsolescencia técnica.
La deuda técnica se refiere a la calidad del código y de la arquitectura de un sistema, tanto de la versión inicial como de la que se ve perdiendo con los años porque los programadores implementan cambios de forma «chapucera» en lugar de tomarse su tiempo para hacerlo correctamente: refactorizando el código, modularizando nuevas funcionalidades, escribiendo nuevas pruebas unitarias y de integración, documentando, etc.
La deuda técnica tiene que ver con las 13 causas que se citan en el artículo de la Wikipedia que referencias al comienzo. La causa raíz, en mi opinión, reside en la (mala) calidad de los desarrolladores. Mientras que es muy fácil escribir código y hacer aplicaciones (que aparentemente funcionan), es muy difícil escribir buen código y buenas arquitecturas (módulos desacoplados, etc.). Para mí es casi un arte, que requiere apreciar la elegancia en primer lugar, para a partir de ahí formarse y practicar de forma continua. Sin embargo, la mayoría de los programadores solo se preocupa de aprender el enésimo framework para JavaScript en lugar de aprender mejores técnicas de desarrollo.
En las grandes empresas de software de EE.UU (Microsoft, Google, Apple, Facebook, etc.) se hacen pruebas de programación a los candidatos (y hay que prepararse para ellas) porque buscan a los mejores programadores. En la mayoría de las empresas no se hace así, se mira el CV, se entrevista sin entrar en cuestiones demasiado técnicas y ni siquiera se pide al candidato que venga con un portátil para enseñar qué código o aplicaciones que ha escrito, o cuál es su cuenta en GitHub para ver qué código escribe.
En estas empresas, se sigue considerando que el software se puede construir de forma industrial, en factorías, por programadores baratos:
Craftsmanship
¿Cuántas empresas cumplen hoy esto, que tiene ya 17 años?:
The Joel Test: 12 Steps to Better Code
Precisamente ahora estoy leyendo «Clean Code: A Handbook of Agile Software Craftsmanship», un libro sobre como hacer mejor código
Hola Rodrigo,
No me he leído «Clean Code: A Handbook of Agile Software Craftsmanship» pero lo tengo en el radar y seguramente me lo compre.
El libro más completo que he encontrado es «Code Complete: A Practical Handbook of Software Construction», de Steve McConnell, un clásico que fue modernizado para su «Second Edition». Es muy completo, como su nombre indica :-) (el doble de páginas que «Clean Code»).
Este tipo de libros deberían ser de obligada lectura para todos los que empiezan en el mundo del desarrollo y formar parte de la biblioteca personal de cada uno (curiosamente son los únicos que me compro en papel, para mi estantería, porque son clásicos que no caducan en un par de años).
Carlos
Me apunto el libro … y puede que sea el siguiente
Es cierto que hay mucha deuda técnica en un montón de empresas. Pero en la profesión de desarrollo de software está creciendo la consciencia de generar mejor código, y el movimiento Craftsmanship es uno de los mejores ejemplos. Este mismo fin de semana ha tenido lugar en Pamplona la 2a edición de la Pamplona Software Craftsmanship. Y la comunidad Craftsmanship de Barcelona, probablemente la más activa de España, celebrará en octubre la 6a edicion de la Barcelona Software Craftsmanship. Conseguir reunir a casi 100 personas durante 2 días para compartir las mejores prácticas de desarrollo de software, profesionales que muchas veces pagan de su bolsillo asistir a este tipo de eventos, no es sencillo pero no es algo aislado. Que este año sea la 6a edición significa que algo está cambiando. Lentamente, pero está cambiando.
Enrique
El problema no es que el HW o el SW se haga viejo. Para eso hay planes de evolución para sustituir los sistemas legacy a sistemas nuevos. Y normalmente las empresas de un tamaño grande lo hacen sin problemas. Pueden ahorrar costes, hacer planes de eficiencia energética e inmobiliaria. (Menos opex por electricidad y comunicaciones, venta de inmuebles sobrantes, etc)
El problema suele ser de incompetencia en la gerencia empresarial, que no saben donde tienen la mano derecha, cuando se premia a un payaso integral por tener su MBA que ha pagado papá fuera del país, que no tiene idea de nada y lo único que tiene dotes es de ponerse medallas en el consejo a costa del trabajo de los demás. Pero claro a esos señoritos 2.0 no se les puede echar, por las relaciones de poder, amiguismo( creo que le llamais ahora networking), y etc, etc.
Por otro lado decir que una dispensadora de tickets es obsoleta por que su interfaz de usuario es de fósforo verde, es pueril pensar que hay reside el cerebro de las operaciones de una empresa como British Airways, de verdad que no reside ahí en un terminal tonto. Que centres tu pobre discurso, enesas pantallas que no te gustan es un síntoma más dela obsolescencia programada que nos envuelve y promocionas.. Sé serio y ético si te acuerdas de que es eso, en los planteamientos y no patines. Donde está la negligencia es en el método gerencial, que hay da igual que tengan el cerebro sin fósforo, o de las «nuevas generaciones» de hijos de papá con su master en indecencia en ética y estética. A años luz de los graduados mal pagados de la Universidad Pública, sin enchufismos que valgan. Esa es la verdadera deuda técnica.
Desconocía el eufemismo de «deuda técnica», creo que mayor claridad supondría el hablar de «software y hardware amortizado y obsoleto»,. Mantener algo en informática, donde los plazos de amrotización son de son de 8 años, 12 años funcionando, es similar a mantener en inmobiliaria, donde los plazos de amortización 70 añós, una casa de más de 100 años.
Desgraciadamente es una realidad muy generalizada, pero no como se puede pensar, en empresas «conservadora» y poco dinámica, que son más fáciles de «renovar», sino por el contrario, en empresas en continuado desarrollo y pleno crecimiento, porque el problema ocurre al tener que destinar los recursos que se tienen para actualizar lo viejo, a seguir desarrollando nuevas aplicaciones y utilidades para cubrir las demandas de las nuevas actividades de la compañía.
En el negocio bancario así ha sido, (y supongo que sigue siendo, porque ya llevo muchos años fuera de ese mundo), He conocido montones de casos en los que se paralizaba y disolvía a medias un proyecto de sustitución de sistemas obsoletos, con tecnologías superadas, para atender nuevas necesidades inaplazables, como podría ser en la actualidad, los desarrollos para los monederos electrónicos, o todo lo que pueda relacionarse con el Brexit.
En momentos de grandes cambios, es una tentación muy fuerte a la hora de elegir, decidirse por realizar aquello que es imprescindible, a consta de retrasar un poco más la sustitución de lo obsoleto. La consecuencia es que en la realidad, se aplaza sustituir lo antiguo «sine die» y se llega al famoso dicho de «si funciona, no lo toques».
«Deuda técnica» no es lo mismo que software obsoleto. La «deuda técnica» surge cuando creas un código a la brava, sin dedicarle mucho tiempo a pensar en como estructurarlo, no tienes pruebas unitarias …es decir, se hace a prisa y corriendo. Cuando quieres modificarlo se encuentra tan enrevesado que te lleva mucho tiempo hacer una modificación que aparentemente es trivial.
Por eso existen las pruebas unitarias, el desarrollo orientado por pruebas, la refactorización y otras técnicas que hacen que la «deuda técnica» disminuya.
Exacto.
Por poner un ejemplo que se entienda: el software del código de la BIOS del PC de IBM de los 80 es software obsoleto, no serviría para los PCs de hoy, con sus nuevos buses y puertos, etc. ni con los avances del EFI/UEFI. Pero seguramente apenas contuviera deuda técnica durante su vida en activo. Su código usa constantes, las rutinas son cortas (dentro de lo «cortas» que pueden ser en ensamblador), está tremendamente documentado, etc. y seguramente seguiría una metodología de pruebas rigurosa.
Irónicamente, hoy he recibido un código fuente de un cliente con una única subrutina de casi 3.000 líneas de código. Como un campeón…
https://sites.google.com/site/pcdosretro/ibmpcbios
Si Alex Cruz (que lleva un año y medio en British) viene de Vueling, es posible que lo hayan elegido justamente por eso, para bajar costes.
Entonces, si está para eso, no se sentirá responsable de los problemas ocasionados por la deuda técnica, y se seguirán viendo, entre otras cosas, los monitores fosforito (la imagen de empresa da igual).
Alguien culpa aquí a los programadores por ser chapuceros. Pero los chapuceros no son necesariamente ellos (que podrá haber algún caso) sino quienes les contratan pretendiendo pagar lo menos posible o sin informarse lo suficiente.
Por lo demás, que empresas como MS, Google, Apple o FB intenten seleccionar bien a los programadores tiene que ver solo con que son tecnológicas (sin buenos programadores no existirían). Y este no es el caso, porque se habla de empresas con deuda tecnológica.
Y ya que se han referido a MS, una pregunta; si de verdad elige bien a sus programadores; como es posible que Windows 10 haya salido al mercado (y continúa) con problemas tan gordos y evidentes como el mal funcionamiento de la herramienta de búsqueda.
Se juntan varias cosas:
– Hay muchos programadores que no saben escribir buen código. Me refiero a cosas muy básicas como usar constantes, no escribir rutinas largas o ponerles nombres adecuados a las clases, métodos, variables, etc.
– Hay muchos otros que sí saben, pero se «descuidan» con más o menos frecuencia, a mí me pasa de vez en cuando :-)
– Programadores que usen cosas más avanzadas de ingeniería del software ya hay muchísimos menos. Digo que «usen», no que «les suene». Ej: pruebas automatizadas, builds automatizados, etc.
Y no es cuestión de que se les pague más o menos. Yo, que he sido un pésimo futbolista, no hubiera sido mucho mejor si me hubieran pagado una pasta :-). Tampoco se arregla con un curso ni con un par de conferencias, requiere mucha perseverancia.
Lo cual nos lleva a un tema en el que Enrique tiene toda la razón: muchos directores de empresa no comprenden la importancia de la tecnología y de cómo puede ser un valor diferencial para su empresa. Se considera una «commodity». En consonancia, ponen a un director de IT inadecuado, que para empezar no tiene pasión por la tecnología, y de ahí para abajo en cascada… se piden «programadores de Java», etc., y la tasa, con el resultado final de que el panorama es dominado por los costes, no por la excelencia.
Como mencionan Rodrigo y Carlos Quintero, se esta confundiendo la «deuda técnica» con la obsolescencia tecnológica y el no querer salir de ella, ambos problemas muy serios y a veces relacionados, pero distintos.
Ojo, no siempre evitar la deuda técnica es lo recomendable, el error es no pagarla a tiempo o no ser consciente de tenerla, esto lo explica mejor.
Totalmente de acuerdo con tu primer comentario, Carlos Quintero, qué manía le tiene este hombre a las pantallas en entorno carácter.
Abandoné el entorno carácter hace ya 30 años pero aún así la cuestión no es si tiene gráficos y colorines o no, la cuestión es si es funcional o no, y hay muchas pantallas con interfaces modernos que no lo son. Y viceversa.
Uno de mis clientes trabaja con Unisys Mapper (BIS), con interfaces gráficos simples, incluso famélicos, pero que funciona en Windows 10 y es capaz de generar documentos PDF y HTML o de hablar directamente con Exel. Sin embargo por su origen en los años 70 del pasado siglo lo consideraría arcaico y obsoleto ¿no? Le puedo asegurar que no lo es en absoluto y ya le ha vencido dos o tres combates a Oracle.
Pues nada, yo espero que alguien que no sea técnico (directivo de esos que menciona Enrique) se digne a hacer aquí algún comentario de lo bonito y útil que es sacar éstos temas a relucir. Que diga que ahora por fin lo entiende, y que ¡muchas gracias!, sería un buen primer paso, al menos, para saber que alguien con poder para cambiarlo lo ha leído.
Enrique, no puedo, ni es mi deseo, alargarme y profundizar en el tema, pero creo que estamos contemplando lo que podríamos denominar una «deuda de Know-how«; lo que dices de utilizar sistemas CRM para gestionar las reservas de vuelos es, a ver cómo te lo explico, una ‘pequeña barbaridad’.
No se puede utilizar un sistema CRM de gestión comercial para sustituir a sistemas de reservas (CRS) o Global Distribution System (GDS) como Amadeus, Sabre o Galileo.
Es como como si explicases que los sistemas de contabilidad bancaria o de Trading HFT están anticuados porque las hojas de cálculo de Excel son más bonitas y estéticas.
Ya lo he mencionado en comentarios en alguna otra ocasión, no sólo es problema de escala, sino un error de concepto, ya la gestión comercial y la operativa están completamente diferenciadas y aunque existan nuevos modelos de acceso online a esos sistemas de reservas, la operativa de las líneas áreas se aleja mucho de ese modelo de gestión de negocio tradicional.
Implica sistemas RTOS de baja latencia y muy sofisticados que no están al alcance del conocimiento de la computación de de uso común, o popular. No es tecnología de andar por casa.
No se puede pilotar un Airbus como si fuera un drone de bolsillo, por muy sofisticado que sea sistema de navegación de este último. Es pecar de ingenuidad, en el mejor de los casos. la misma expresión ‘Legacy’ es un término que está ya en desuso.
Esto me hace preguntarme si la deuda técnica acabará apareciendo sí o sí a largo plazo en cualquier empresa por mucho que diseñen sus sistemas con la tecnología más moderna en ese momento.
Por tanto, cuando una empresa lleve tiempo, inevitablemente tendrá unos costes de actualización de sistemas que un nuevo jugador entrante no tendrá y por tanto una desventaja competitiva que puede hacerla caer.
¿Es posible para una empresa de grandes dimensiones ser ágil en la actualización de sistemas como para no generar una desventaja competitiva respecto a nuevo jugador? Y no me refiero a empresas como BA, sino a empresas como Facebook o Airbnb que a muy largo plazo podrían sufrir problemas similares…
Gracias
Estimado Enrique, cuando dices
tu ánimo de justificar tu punto de vista te ciega. No porque algo sea anticuado es menos fiable. Más bien al contrario: un sistema correctamente mantenido durante años es, por su propia evolución, un sistema que cada vez tiene menos bugs, un sistema maduro. Un sistema estable. Un sistema fiable. Todo lo contrario de lo que tú sugieres.
No confundas un sistema simplemente antiguo con un sistema mal mantenido durante años. En general estás más al día de nuevas tecnologías que yo, y por eso siempre sigo tus artículos. Pero también noto a través de tus artículos que pareces deslumbrado por ellas.
Si una pantalla verde es equivalente a compañía en riesgo tecnológico, la mayoría de los bancos españoles estarían a punto de colapsar. Muchos de sus sistemas siguen basados en mainframes de los denominados «legacy» que solo entienden de hacer transacciones.
Pero, ¡Como las hacen!. rápidas, fiables, seguras…
Sin embargo, la tecnología es precisamente uno de los valores que más competitividad aporta a los bancos españoles cuando les comparas con los del resto del mundo.
Verás pocos procesos de integración entre un banco español y uno extranjero, en que el sistema transaccional que han adoptado al final, no sea el del banco español.
Está claro que el problema de la banca española no han sido los sistemas de información, por muy «legacy» que sean o mucha pantalla verde que tengan. Ha estado en otra parte.
La deuda tecnológica, existe, pero las pantallas verdes no son la forma de localizarla. Hay más incidencias en los modernos sistemas de venta de entradas por internet (algunos los hemos vivido), que por ejemplo, en los veteranos sistemas de la mayoría de las compañías de seguros.
Por cierto, uno de los sectores, este de los seguros, más dinámicos desde el punto de vista tecnológico y de la digitalización y uno en los que más compañías siguen confiando a sistemas legacy el registro y procesamiento de sus datos.
Ahí está el error de muchos tecnólogos: creer que el éxito consiste en la ausencia de incidencias. Durante años, se ha juzgado a los tecnólogos por un solo ratio: «que el sistema no se caiga». Y esos sistemas de pantalla de fósforo verde serán muy estables, pero son una mierda, un puñetero silo que genera una deuda técnica brutal al impedir que la información se integre en otros sistemas más modernos y dé lugar a nuevas posibilidades. El problema de muchos tecnólogos es la obsesión con la estabilidad: si tu misión es que el sistema sea estable, dejarás de innovar y de probar cosas nuevas, porque innovar y probar cosas nuevas siempre compromete la estabilidad…
un puñetero silo que genera una deuda técnica brutal al impedir que la información se integre en otros sistemas más modernos y dé lugar a nuevas posibilidades.
No lo impiden, para eso existen interfases que traspasan la información de un sistema a otro, pero si es verdad entorpecen y complican.
Lo que nadie ha tenido en cuenta es el factor tiempo.
Se pueden poner más recursos, (en teoría, porque los recursos son limitados). para desarrollar una aplicación, pero no más tiempo. Se suele trabajar contra reloj, por que las necesidades son acuciantes,
A todos nos gustaría hacer las cosas perfectas, pero al tenerlas que hacer en el tiempo disponible, se acortan tiempos de donde se puede y eso es siempre de un revisión en profundidad de las diferentes fases de análisis y de la puesta a punto, (pruebas), final de los programas,. Si a eso se añade que las posteriores correcciones son «parches» urgente, que se hacen ya en explotación, ocurre que al cabo de muy poco tiempo la información que se tiene de la aplicación no es fiable, por posibles parches no documentados que se hayan hecho y lo único fiable es analizar los programas.
No digo que esta sea la mejor forma de actuar, sino que esta es la que se practica, y que viene obligada por la realidad, los medios y el tiempo disponible. Desgraciadamente una vez mas, lo perfecto esta reñido con lo bueno
Y esos sistemas de pantalla de fósforo verde serán muy estables, pero son una mierda, un puñetero silo que genera una deuda técnica brutal al impedir que la información se integre en otros sistemas más modernos y dé lugar a nuevas posibilidades.
Que no señor Dans, que no es así, que se deja cegar por los iconitos y se pierde lo que realmente importa.
En general Mapper se utiliza en entornos no gráficos y si los viera usted pensarían que son una «mierda», un pozo aislado. Si viera usted nuestro ERP, en cambio, con su interfaz gráfico, no dejaría de alabarlo al verlo comunicarse con todo tipo de sistemas, generar documentos html o PDF y hablar con MS Office. Y todo ello ignorando que el que permite todo esto no es el interfaz gráfico sino el motor del lenguaje.
Este comentario es realmente de Enrique Dans o de alguien que usa su nombre?
No entro en si tiene razón, pero la frase «son una mierda, un puñetero silo» me parece fuera de lugar.
Creo que los silos, los problemas de integración, … no dependen del lenguaje de programación sino de su diseño, desarrollo e implantación. Sinceramente, creo que muchas empresas con sistemas legacy tienen ahora mismo más problemas para renovar su front-end de sus oficinas o de sus páginas de internet que para desarrollar sobre los sistemas mainframe.
Has puesto un buen ejemplo con el sector seguros, que he conocido profesionalmente.
Se usan muchos sistemas que para los «tecnólogos de MBA» son obsoletos y anticuados. Básicamente porque todo lo que no se pueda manejar con un ratón o desde su «Smartphone» es la forma que tienen de clasificarlo.
Algunas veces aterriza en la dirección un «paracaidista con MBA», que viene de vender detergentes o similares, y decide que hay que cambiar los sistemas por ERPs y CRMs «del mercado» .
Y los resultados son un desastre. Sistemas que necesitan hardware 4 o 5 veces mas dimensionado que los antiguos, imposibilidad de adaptarse a los requisitos de usuario, tiempos de desarrollo eternos. Bueno, o tiempos normales, pero cuando alguien dice que un CRM se implanta en 3 meses, les dices que al menos se necesita 1 año, y al final desde fuera de la empresa ves que son 3 años con un 50% de la funcionalidad del sistema al que sustituyen pues solo te queda pensar un «te lo dije».
Luego descubres que la razón principal de hacer las cosas de un modo o de otro es que es mas «interesante económicamente» (y lo dejo entrecomillado) contratar consultoras y desarrolladores externos que mantener los departamentos de desarrollo internalizados, y ya empiezas a comprender muchas cosas.
Es cierto, Enrique: hace un par de años he tenido que ver como un vendedor de Renfe por ventanilla tenía que imprimir parte de un trayecto para luego poder expedir un billete con trasbordo porque el sistema no permitía… era una ventana con el fondo negro y sólo carácteres… hacer interfaces, wrappers, etc… para esos sistemas es una auténtica pesadilla. Normalmente se gastan más recursos en mantener vivo ese zombie que empezar el código desde cero, algo que muchos empresarios retrógados no ven.
Cualquier estudiante de informática es capaz de crear un sistema que sea capaz de generar billetes con trasbordos teniendo en cuenta los tiempos de trasbordo sin problemas… pero Renfe como tenía -desconozco si ahora sí lo han resuelto- un sistema legacy… esa deuda técnica es muy grande y hace que sus empleados tengan que perder mucho tiempo en generar dichos billetes.
Otro tema que me gustaría señalar es las subcontratas de empresas de software, las llamadas «Cárnicas»: empresas con total falta de profesionalidad que se nutre a base de «carne fresca» (a.k.a. becarios) a muy bajo precio, ofrecen a sus clientes plazos imposibles de cumplir y explotan hasta el límite a los becarios, con lo cual al final las cárnicas obtienen lo que pagan: un código deficiente.
Opino que la deuda tecnica siempre existira en mayor o menor medida. Hay que recordar que la ingeniera de software es una disciplina relativamente joven. Cuando se empezo a desarrollar software se tomo como ejemplo otras disciplinas, como la arquitectura, etc con sus metodologias hard del tipo waterfall, por que no existia otra cosa. Con el tiempo y la experiencia surgieron las metodologias Agile que se adaptan mejor a la naturaleza tan cambiante del software.
Hoy en dia, gracias a las nuevas metodologias y practicas, el problema de la deuda tecnica se tiene mas en cuenta. Aun asi, loas tecnologias cambian tan rapido que es dificil mantenerse sin deuda tecnica por completo. Ademas, la empresa manda y no siempre va a ser prioridad la deuda tecnica sobre otros objetivos igual o mas importantes, por lo que los ingenieros tienen que seguir las pautas que les mandan desde arriba. Aunque nos esforzamos en aconsejar lo que creemos conveniente. Ademas, suponiendo que convenzas a business para que invierta recursos en reducir la deuda tecnica, esos recursos son a veces limitados, ya que no todas las empresas son tan poderosas en recursos como Google o Facebook.