Las TIC vistas con una preocupante perspectiva de una analogía con la burbuja financiera.
Portada
mis comunidades
otras secciones
Comentarios
El artículo es muy bueno y el concepto de deuda técnica está arraigado como un cáncer en el tejido empresarial español: por lo general no se documenta nada, no se depura lo suficiente, no se hacen pruebas de casi nada y todo lo que no sea apagar fuegos y cortoplacismo está visto como una pérdida de tiempo. No solo en desarrollo de software, sino en todas las disciplinas relacionadas con la informática. Desde la administración de sistemas hasta la implantación de redes.
Lo único que me rechina es lo de citar a Leopoldo Abadía...
#1 Efectivamente, me pasó lo mismo con la cita de L. Abadía, pero creo que la introdujo para explicar el concepto de "porquería" y su acumulación.
El artículo es excelente. Que cite a Abadía, como bien dice #1, igual no es muy relevante. Lo que sí que no entiendo es porqué la noticia tiene el icono de vídeo, que es de lejos mucho menos relevante que el texto de la noticia.
Como consultor y arquitecto de sistemas Web que soy, puedo jurar que eso se da en todas las consultoras y, muchas veces el cliente te pide parches para seguir igual¿?, increible pero cierto, una aplicación wap/web que corre sobre un jboss y tiene una media de 50000 transacciones diarias se coma la maquina sobre la que va instalada (2 CPUs Sparc 1300Mhz, 6Gigas de Ram, muucho disco duro y Solaris la aplicación se cuelga incluso en horas valle, me deja sin hilos el jboss, se come los fildescriptors del sistema y entre las 22:00 y las 9:00 esta al 100% de uso de CPU, cual es la solución aportada por noosotros (a petición del cliente)?, como el código no es nuestro y hacer una reingenieria es muy caro y el cliente no quiere, pues ponemos mas maquina, burrada supina, ahora tiene un SunFire 25K con 64Gigas de Ram, 32 CPUs (Dual core) y Solaris 10 y ohhhh!!! como ya dije en su momento, se comporta exactamente igual se sigue colgando y el cliente se ha gastado una pastizal en un cacharro que chupa mas luz que medio Madrid, disipa calor pa aburrir y esta infrautilizado, pero como dice el cliente, caballo grande, ande o no ande y no me metas más aplicaciones en la maquina que sino me quedo sin recursos ¿?. Así nos va
Aqui un consultor de una aplicación con el core en COBOL
El COBOL nos jubilará a todos. ¿Porqué? Porque en tratamiento de datos batch a nivel gigante, le da sopas con hondas a cualquier otro lenguaje
#11
#11 ¡Larga vida al COBOl/CICS/DB2!
#15 que gran argumentación, me has convencido!.
#33 No tiene que ver el lenguaje con la eficiencia. Podrás ver algoritmos pésimamente implementados en C, y otros brillantemente implementados en COBOL.
La eficiencia en el caso que dice #11 se da porque hay un mainframe de tropecientos millones de Cristianoronaldos corriendo el programa COBOL, que probablemente ya esté amortizado.
No vamos a empezar un flame ahora, pero decir que COBOL es mejor lenguaje que X (para todo valor de X) es, como mínimo, faltar a la verdad - IMHO por supuesto
#35 Cuando ha dicho COBOL yo he entendido COBOL/CICS/DB2 y la arquitectura Host que ello implica. No tiene sentido hablar de rendimiento de un lenguaje en sí mismo
#39 CICS? Vaya mariconada. Donde esté un IMS que se aparten los juguetitos
(Esto empieza a parecerse a una pelea de dinosaurios).
#40 Todo ello acompañado de un teclado IBM de 2,5 Kg.
#11 Recuerda la máxima: si algo funciona... Por cierto, he estado mirando y los empleos relacionados con COBOL (pocos, pero hay) están bien remunerados, ¿no?
#26 Están, digamos, por encima de la media del mercado. Piensalo, hay poca gente, por lo que es facil encontrar algo bien pagado. Yo de momento no me quejo, me da para vivir yo solito en el centro de Madrid desahogadamente
Así que yo te animo a ello
#11 Con permiso del PL/I, claro...
Coñas aparte, se pueden desarrollar maravillas y chapuzas en cualquier lenguaje. La abundancia de la porquería tiene más que ver con la megaestafa llamada outsourcing que con los lenguajes o arquitecturas usadas. Se trata de una burbuja charcutera en toda regla.
Si señor... eso de que hay más jefes que indios... o una solución que se vende porque ya está hecha, se implanta en un mes y... o sorpresa, no hay ni un sólo documento con los requisitos, ni la más mínima idea de que utilizar... bueno pero con el framework que tenemos es bastante... claro hombre, sino fuera porque es de los años 90.
#2 Últimamente me he topado varias veces con una variante de lo que comentas. Yo lo llamo el "efecto IBM*", pero seguro que tiene un nombre oficial. Quizás la mejor forma de describirlo sea con una puesta en escena:
- Pero, ¿has evaluado la posibilidad de hacerlo con SW Libre?
- Mira, si elijo SW Libre y no funciona, me van a caer todas las culpas, si elijo IBM no me pueden arrimar ninguna culpa: "yo elegí IBM ..."
- Sí ..., ya ... Y ¿hay un plan de sistemas coherente con lo que has elegido?
- (esto normalmente no se llega a decir) Supongo que ya viene incluido con la compra
*) Quien dice IBM puede decir otra marca de relumbrón. Uso IBM porque esta situación solía suceder hace algún tiempo, quizás demasiado, a la hora de hacerse con un mainframe.
#6 creo que ahora se sustituye IBM por Accenture, que en teoria te entrega un paquetito muy mono y con un lazo enorme, pero las frases son identicas.
No creo que sea una analogía adecuada, porque la deuda técnica, al menos en aplicaciones desarrolladas a medida para otras empresas, no puede causar algo equivalente a un martes negro (si hubiera que tirar todo a la basura y rehacer de nuevo, sería más trabajo para las TIC). Esto se podría aplicar a todas las disciplinas: Por ejemplo, por lo general las empresas no compran sus coches fijándose en la lista de marcas con más fallos, ni se construye un edificio preguntando al constructor si el edificio va a durar en pie 100 años o 200, ni se compra material de oficina investigando su duración, ni se instala una calefacción fijándose en las predicciones energéticas de las próximas décadas. Y mientras los coches se rompen y las empresas quiebran y vuelven a empezar, siguen usándose programas hechos en COBOL...
#5 Es difícil que se llegue a un martes negro a nivel mundial, pero la analogía no pretende llegar tan lejos. La analogía se refiere a cómo funcionan los mecanismos en sí, que combinan ignorancia, irresponsablidad y en algunos casos un poco de soberbia y van formando la bola.
Pero sí se puede llegar a una situación de desastre dentro de una organización cuando haya una dependencia muy fuerte de las TIC. Desastre significa un nivel de incidencias que la organización ya no puede soportar y que el departamento TIC no es capaz de controlar y/o que los costes y/o necesidad de personal se disparen hasta un punto que tampoco se pueda soportar ni remediar a corto plazo.
Vamos, esto es lo que yo siempre he oído con el típico "aquí cada uno ha ido dejando su cagadita", pero en plan fino.
Pues vale, la próxima vez procuraré hablar de que "la aplicación tiene una gran deuda técnica que impide la sinergización de trócolas", que se note que somos ingenieros, coño.
Para entender lo de Leopoldo hay que ver el vídeo entero, explica el mecanismo de como la burbuja financiera se puede formar a base de vender productos que nadie entendía muy bien. Y además lo hace con mucha gracia.
Trasládalo a cómo se vende software y los proyecto en la mayoría de los casos, ya sea a medida o incluso en muchos casos paquetes terminados.
Luego piensa en cómo lo compra el cliente y qué conoce en realidad de lo que está comprando, sobre todo visto a futuro...
El funcionamiento es básicamente igual que el de la banca de inversión en su momento.
efecto menéame, aqui esta en cache de google http://webcache.googleusercontent.com/search?q=cache:QnfehFwQTQAJ:www.microlopez.org/2011/02/11/deuda-tecnica-la-burbuja-de-las-tic/+http://www.microlopez.org/2011/02/11/deuda-tecnica-la-burbuja-de-las-tic/&cd=1&hl=es&ct=clnk&gl=es&source=www.google.es
Más que una burbuja, yo lo veo como un juguete de esos en los que soplas y salen muchas pompas.
El ciclo es:
1. Se desarrolla a lo loco.
2. Se prueba.
3. Se corrige sobre la marcha.
3.1 Surge marronazo. La burbuja opompa, estalla.
3.2 Si el problema es muy grande, GOTO 1.
Al menos, aunque sólo sea un paso, ahora existen herramientas que ayudan a mantener en ciertos aspectos la calidad de los desarrollos, avisando de los posibles fallos en un tiempo relativamente corto. Pero claro, esto sólo es una ayuda. Sin documentación correcta, y con APIs de terceros que ya son castillos de naipes, este paso se queda en pasito.
Deuda técnica = procrastinar lo menos urgente. De toda la vida.
Permitidme que haga un símil con la burbuja inmobiliaria, ya que el artículo propone este paralelismo:
Si nos fijamos en la burbuja inmobiliaria, vemos dos grandes actores. El primero son las inmobiliarias y los bancos, que en este caso corresponderían a las empresas de software. En particular, el agente inmobiliario vendría a ser el consultor/analista.
Por otro lado tenemos a las personas que decidieron comprarse un piso, que en este caso corresponderían con la empresa cliente que desea un software, sea a medida o uno genérico con adaptaciones.
¿Dónde encajan aquí los programadores? Pues al ser la parte técnica del asunto, supongo que podríamos hacer el paralelismo con el tasador de pisos.
Supongo que todos estamos de acuerdo en que son los dos primeros actores quienes provocan la burbuja. Unos por avaricia, y los otros por otro tipo de avaricia, al empeñarse en comprar a toda costa, por aquello de que "los pisos nunca bajan". Igualmente, la empresa de sofware sólo quiere facturar, y la empresa cliente ahorrar el máximo dinero y que le den el producto enseguida.
Pero la avaricia rompe el saco, en un caso y en otro.
¿Y en medio? Pues en el primer caso hay un señor que se dedica a tasar el piso y al que el banco presiona para que lo tase muy por encima del valor real. En el caso del software, al programador le imponen unos plazos imposibles, con unas especificaciones que dan risa (eso cuando las hay, que no es habitual) y sin posibilidad alguna de comunicación con el usuario final, que es quien mejor podría aconsejarle. ¿Resultado? El piso está tasado por mucho más de lo que vale, y el software es inservible. ¿Tienen la culpa estos dos señores? Probablemente no, sino que se han limitado a ejecutar lo que impusieron los actores mencionados más arriba.
En el primer caso, el batacazo de la crisis ha servido para abrirle los ojos a la gente. Ahora ya nadie dice que los pisos nunca bajan. Pero en el segundo, aún falta que algunos se peguen una buena hostia para que se den cuenta de que la calidad, la comunicación y el trabajo en equipo, no son un gasto, sino una inversión.
#27 la calidad, la comunicación y el trabajo es un gasto, no te equivoques. Otra cosa distinta son los beneficios conseguidos al arriesgar al asumir esos gastos. Sin ánimo de crítica destructiva.
Si hablas con alguien que ofreces un producto que en 5 años en adelante le va ser rentable respecto a otro, le estás diciendo que va perder dinero durante 5 años, y dejas caer que no piensas que en 5 años no va aparecer nada que lo haga mejor y más barato, le estás vendiendo un gasto por no ser capaz de venderlo barato que seguramente cuando sea rentable y después de problemas, pelotazos y demás vaivenes podrá comprar otro producto mejor que el tuyo.
En 5 años una empresa va a quiebra o pega tal pelotazo que puede comprar lo que quiere, ésa es la base.
#32 la calidad, la comunicación y el trabajo es un gasto, no te equivoques. Otra cosa distinta son los beneficios conseguidos al arriesgar al asumir esos gastos
Por eso mismo digo que es una inversión, no un gasto sin más. Porque se hace como una apuesta para ganar más de lo que se gasta.
Por otro lado, no hace falta esperar 5 años ni mucho menos para notar los efectos de la calidad y de una buena comunicación. Al revés: muchas veces los proyectos se alargan mucho más de la cuenta y las empresas se pasan años mareando la perdiz, precisamente por no hacerlo.
La creencia de que prescindiendo de la calidad se hacen cosas más rápidas y baratas es una simple superstición. Al menos mi experiencia me dice todo lo contrario. En el software se aplica muy bien lo de "vísteme despacio, que tengo prisa".
Exacto, las consecuencias directas de la cultura del pelotazo aplicado a la tecnología, lo importante es lograr el gran contrato y cobrarlo, lo demás no importa. El efecto es el mismo en todos los sectores, descapitalización y endeudamiento. A ver si de una vez por todas les da una huesitis a esos engreidos entrajetados.
Hay una razón mayor que en el tema de los paquetes de deuda que permiten vender deudas con diferentes riesgos asociadas en una, y esto son el hecho de que los bancos centrales fijan sus tipos de interés no dejándolos por oferta y demanda, sino lo fijan de forma artificial diseñando la política financiera lo que choca frontalmente con la creencia popular de que vivimos en una economía de mercado.
Si los tipos de interés son demasiado bajos los empresarios se animan a realizar proyectos que no deberían ser rentables, tales como vivienda, o conceder hipotecas a 50 años locuras así, finalmente como el mercado es muy eficiente para corregir estos errores una vez que detecta el problema se produce lo que llamamos estallido de la burbuja, que no es más que la absorción y reestructuramiento de la economía hacía proyectos que si son rentables realmente.
Yo creo que esto es como todo lo nuevo hasta que se regula, nadie sabe mucho acerca de él y el que sabe calla.
¿Por qué? porque el proveedor si diseña un producto bueno que le cuesta 150h y dura 20 años sin problemas su cliente posiblemente no vuelva a contratarle hasta entonces. Si por el contrario le vende una chapuza que aveces ni el autor es capaz de averiguar como lo ha hecho seguramente a los X meses para cualquier cambio tenga que volver a contactar con su proveedor y asi pasa por caja más veces aunque en un principio parecia más barato y más rápido desarrollando ese producto que la competencia.
Que grande el señor Leopoldo
Estoy totalmente de acuerdo con tu artículo: capa de negocio, capa de acceso a datos, logs, baterías de pruebas, … aplicar las mejores prácticas posibles en los proyectos.
En lo que discrepo es que el uso de buenas arquitecturas de diseño, prácticas y calidad, supongan al proveedor mas esfuerzo y peor productividad. Al revés, con un buen framewok aunque no sea de los populares, aunque sea realizado por el propio proveedor, se agiliza el desarrollo y se entrega al cliente un software de calidad, escalable, mejorable, mantenible en el tiempo …
El problema está en la ignorancia e incultura de los gerentes de la empresas, solo quieren beneficios para el presente año y no hay visión a largo plazo. Luego pasa el tiempo y nos encontramos con N veces repetida la lógica de negocio, no en la misma aplicación, si no entre todas las aplicaciones de la empresa y viene luego la integración de aplicaciones para crear una nueva lógica de negocio para tratar de integrar todas … un desmadre
En mi caso particular, hace un par de años, lleve un proyecto con arquitectura mvc, daos, logs …. sobre todo conseguir una única lógica de negocio, reutilización constante de la lógica, evitando que se pudiera duplicar lógica de negocio, introduciendo al modelo vista controlador, el componente manager (gestor), que no es interface de usuario, que no es base de datos, que no es servlet, la lógica de negocio por si misma independiente de su implementación, contenedor, bb.dd …
Ahora me encuentro en juicio con el cliente, por qué según él no se terminó el proyecto a tiempo, de las 270000 líneas de código fuente, el perito informático de la demanda solo ha detectado 4 errores, que no lo son. El problema está que los jefes, directores, responsables de las empresas: son unos paletos ignorantes que se creen que estamos programando en visual basic un programa de escritorio, cuando en realidad estamos desarrollando proyectos cliente servidor, multiubicación, multiplataforma, multidispositivo, ...
Hay directores y gerentes que se salvan, pero son la excepción que confirma la regla
En cambio si el desarrollo lo hubiera realizado en scripting puro y duro: html, estilo, jps, sql, javascript todo en uno, repitiendo componentes, sentencias sql, a diestro y siniestro, que era lo que tenía el cliente, éste no se hubiera dado cuenta de nada, ni le habría importado lo más mínimo, aunque dudo si hubiera tardado más o menos en desarrollar la aplicación, seguro que más, aunque el copy y paste por todos los lados, a lo mejor hubiera agilizado algo, pero claro depurar un error, hubiera sido de chinos.
Estoy de acuerdo, pero ten cuidado, lo que prima es el precio y la fecha de entrega, aunque el año que viene la aplicación sea imposible de mantener y hacer mejoras, imposible de detectar un error.
Si lo haces barato y rápido. Por suerte un profesor me enseño “bueno, bonito y barato” elije dos.
Ahora me encuentro demandado por hacer las cosas bien, aplicar las mejores prácticas, en próxima vista previa de juicio, cuentame tú como le explicar a abogados y jueces eso de : capa de negocio, capa de acceso a datos, logs, baterías de pruebas, …
Como colofón, el que me demanda, caradura sinvergueza, dejo de pagar al final del proyecto, ahora la empresa Cip Informática, Centro informático pozuelo SL, tiene entregado el 87% del proyecto y solo tiene pagado el 60%, pero me demanda porque un abogado le dice que puede conseguir que el proveedor le devuelva el 60% de lo que pagó, porque el perito informático, Profesor Verdejo, de la universidad complutense de Madrid, ingeniero en informática, dice que tengo 4 errores y que mi diseño Modelo Vista Controlador, no es aprovechable por otros programadores.
Cágate, además de los empresarios caraduras, los profesores de informática de la universidad complutense de Madrid, matemáticos frustrados, se ponen de parte del empresario del házmelo rápido y barato
La nueva burbuja de las IT es el ITIL... La religión ideal para los de gestión y los gurús cancamuseros.
Pienso que el SAAS Va a convertir este problema (y otros como la piratería) en historia. Las empresas no compraran software, sino servicios que serán pagados por su uso y si no le dan el servicio, se irán a otro lado.
Un ejemplo: salesforce.
#18 ITIL es un conjunto de buenas prácticas. Unas recomendaciones que cada empresa debe decidir si le interesa aplicar o no. ¿Dónde está la cancamusa?
#28 En los gurús que dan simposiums y en que se está convirtiendo en una religión para algunos y en una forma de vender la moto para otros.
¿Qué cojones significa TIC?
Y no me digáis, leete la noticia, yo primero leo la entradilla, leo un par de comentarios y si eso, me la leo.
#19 Lo tuyo es el ansia del saber y de la curiosidad ...
#19 http://www.google.es/search?q=TIC
El primer resultado te da la respuesta
#22 Soy muy vago para mover el ratón hasta el cuadradito del google. Por eso quiero fomentar con mi anterior comentario que si se pone un acrónimo en meneame, que por favor se diga que significa.
#23 es perfectamente razonable (y mas en una entradilla tan corta). Tienes razón.
#19 http://www.usaelputogoogle.com/carlos.php