Gracias a un este simpático artículo en Barrapunto y un tweet de @juankipe me he topado estos días atrás con el concepto de la “deuda técnica“, el cual desconocía y me hizo gracia por las paralelas con los recientes acontecimientos en el mundo financiero, lo cual le confiere cierta actualidad. Se trata de un problema que desgraciadamente sigue dándose con demasiada frecuencia en las TIC, especialmente en el desarrollo de aplicaciones a medida, en las que se centrará este artículo, y que se demandan con frecuencia, por ejemplo, en el ámbito de la Administración electrónica.
La deuda técnica es una metáfora de Ward Cunningham que describe como hacer las cosas rápido y mal va generando, con mecanismos propios de las burbujas financieras, una deuda similar a nivel técnico. En realidad el problema no es nuevo en absoluto en el mundo del software, se puede ver como una variante de lo que ya fue denominado en los años 60 como la “crisis del software”.
La deuda técnica tiene asociado el pago de intereses que se concretan en el esfuerzo extra necesario en el futuro por una elección rápida y mala de diseño, la cosa va creciendo y se vuelve cada vez más insostenible. Al igual que en el mundo financiero, si te pasas, el exceso acabará en un gran desastre del cual, en el mejor de los casos, se “sale” con un costoso rescate que conlleva una nueva deuda como lo puede ser en las TIC la sustitución apresurada de un sistema o conjunto de sistemas ante un problema inminente e insalvable, fruto de errores pasados, por otros nuevos que tampoco se han examinado lo suficiente.
En otros casos el desastre a nivel informático puede ser más sutil, pero no menos importante: se puede manifestar en una estructura de costes que al haber perdido control va creciendo poco a poco hasta un punto que pone en duda el sentido de las aplicaciones en cuestión o dicho de otro modo: que la supuesta mejora de productividad que se logra con la utilización de estas aplicaciones corporativas se vuelve negativa.
Igual que en la burbuja financiera, como muy bien explicó en su día el gran Leopoldo Abadía en el vídeo de abajo, todo esto resulta en definitiva en una acumulación insostenible de lo que Leopoldo denomina “porquería” en la entrevista que le hace Andreu Buenafuente en el vídeo. En el mundo de las finanzas esto ocurrió con los productos opacos de paquetes de deuda revendidos con bonitos nombres múltiples veces. En el mundo de las TIC ocurre con muchos de los desarrollos a medida y algunos de los paquetes de software que adquirimos.
Me sorprende que en el año 2011 siga habiendo tantas empresas, muchas de ellas de “primera fila”, cuya forma de trabajo encaje en esta metáfora. Por tanto, en el artículo me quiero centrar no tanto en la perspectiva técnica de este concepto de deuda, sino en la mentalidad de estos proveedores TIC y también del cliente que acepta sus prácticas, ya sea por no detectarlas o por tolerarlas.
Siendo un problema grave como es, me voy explayar un poco más a lo largo de varios post. En el primero nos centraremos en la naturaleza del problema.
La filosofía de las “hipotecas basura” llevada al desarrollo de software
Tanto por mi experiencia en su momento como trabajador en el sector privado, la experiencia en mi organización actual, las experiencias que relatan compañeros en otros destinos, lo que me transmite el personal de los propios proveedores (personal de todo tipo: desarrolladores, consultores, comerciales, directivos) resulta evidente que todavía en muchas de las grandes empresas del sector la visión estratégica en la línea de negocio del desarrollo a medida e integración de software es similar a la habida en su momento en la banca de inversión: una visión centrada en los resultados económicos a corto plazo descuidando la visión a medio/largo plazo, con un exceso del peso de los aspectos financieros sobre los aspectos propios del negocio, o dicho de otra forma: la técnica del avestruz combinada con la huida hacia adelante.
Esto se manifiesta en que el hecho de que cuidar su propia productividad y unos mínimos de calidad en el desarrollo de las aplicaciones entregadas al cliente no parece ser una prioridad para estas empresas. En ellas no se toman medidas o no se implantan en serio actividades como el control de calidad, la formación continua de su personal y la definición e implantación de buenas prácticas y patrones de diseño que aseguren la calidad de sus productos, lo cual a la postre conllevaría mejoras muy significativas en la eficiencia y productividad de la propia empresa y por tanto de su competitividad en el mercado.
Medidas como éstas producen resultados incluso en proyectos relativamente pequeños (de unos pocos meses) y su impacto crece de manera exponencial con el tamaño del proyecto, además de impregnar a su plantilla con una cultura de calidad. El resultado final es que en los proyectos el esfuerzo decrece y la calidad aumenta. Eso significa menos coste, más eficiencia, más productividad y más calidad.
Que esto ocurra en empresas pequeñas de unas pocas decenas de empleadas es criticable, pero resulta mucho más incomprensible en empresas con cientos o miles de empleados y a las cuales, por su tamaño, esta pequeña inversión de tiempo y recursos humanos les resultaría muy asequible y muy rentable.
Lo que más me sorprende cuando inspeccionamos las aplicaciones en mi trabajo es la naturaleza tan básica, tan trivial de las malas prácticas que observamos, sobre todo, porque siguen patrones que en la ingeniería del software están perfectamente identificados y para los cuales se conocen perfectamente los patrones de diseño óptimos, incluso en muchos casos con aplicar simplemente un poquito de sentido común ya bastaría.
Ejemplos reales de malas Prácticas habituales
Para concretar y ver lo básico que llega a ser la manera en la que se manifiesta este tema voy a pasarme un momento a un plano algo más técnico. Ejemplos habituales que nos encontramos cuando revisamos “las tripas” de los trabajos que se van entregando son cosas como las siguientes:
- Aplicaciones Web sin una capa de lógica de negocio, con la lógica codificada en las propias páginas y parcialmente repetida decenas de veces a lo largo de ellas que las vuelve inmantenibles con un esfuerzo razonable y produce otros efectos como no ofrecer un API para la integración con otras aplicaciones. Todo un “clásico”.
- Tres cuartos de lo mismo es cierto para la capa de acceso a datos (patrón de diseño DAO), otro “clásico”.
- No utilizar logs o no aprovecharlos bien para volcar información de interés sobre errores, etc.
- No utilizar juegos de pruebas automatizados que con herramientas gratuitas actuales, como JUnit en el caso de emplear Java / Java EE como tecnología, se crean muy fácilmente y resultan muy productivos en cualquier proyecto no trivial.
- Etc., etc., etc.
Observamos que, en general, prácticamente hay que “forzar” a la mayoría de las empresas para que hagan estas cosas, de ellas no sale, incluso cuando se han especificado desde un principio en los pliegos para que podamos exigirlas. Podríamos continuar con más ejemplos en esa línea y, si hilásemos más fino, la cantidad de ejemplos sería casi infinita.
En fin, cualquiera que tenga un poquitín de conocimientos de desarrollo de software estará de acuerdo que no estamos hablando de aspectos avanzados ni sofisticados, estamos hablando de los mínimos de una aplicación con un diseño aceptable, lo que lleva siendo ya más de una década el ABC del desarrollo de software con las tecnologías actuales.
Por otra parte, me sorprende ver que resulta habitual ver que estas mismas empresas presenten una nutrida relación de certificaciones de calidad y metodologías en los procedimientos de contratación.
Certificaciones de Calidad CMMI, ISO 9000, ISO/IEC 20000, etc. Todo estupendo, pero cuando revisas un poco las tripas me preguntó cómo se han implantado estos sistemas de calidad y cómo han obtenido estas empresas la certificación, porque la calidad del producto final desde luego que no la refleja. Personalmente las únicas certificaciones en las que he podido observar en ese sentido un efecto tangible claro para el cliente y por tanto ciertas garantías son las certificaciones técnicas de los fabricantes que acreditan a los profesionales en un determinado producto o servicio.
No quiero entrar en el problema del desfase entre las promesas de estos sistemas de calidad y la calidad del producto/servicio final que recibe el cliente, a eso habría que dedicar otro artículo entero, pero hay un hecho que está ahí y que se observa con claridad: una gran parte del software desarrollado en el sector sigue siendo realmente malo, a pesar de que ya se lleva hablando hace casi medio siglo de este tema.
La Calidad como seña de Identidad en las Comunidades de Software libre y de Fuentes abiertas
Por otra parte, en las grandes comunidades de software libre y de fuentes abiertas se observa justo lo contrario en lo que se refiere a la calidad de sus desarrollos, comunidades, por cierto, que durante mucho tiempo han sido despreciadas por una gran parte de los responsables TIC, tanto en el sector público como el privado. Una actitud que se sustentaba en la ignorancia del funcionamiento de estas comunidades y los modelos de negocio que se han formado a su alrededor y mitos como que el software de este tipo no dispone de servicios profesionales para su mantenimiento.
Resulta en ese sentido irónico observar que comunidades basadas en colaboradores voluntarios como la encabezada por Linus Torvalds (responsable del desarrollo del “kernel” de Linux) o la Fundación Apache famosa por proyectos como su servidor Web (el nº1 del mundo) y su extenso catálogo de librerías y productos, especialmente en Java, han conseguido desde hace ya tiempo un notable prestigio, entre otras cosas, por los altos estándares de calidad que cumplen, por lo general, sus procesos y productos. De todas formas, es necesario matizar que los grandes fabricantes como IBM, Oracle o Red Hat tienen intereses estratégicos en el desarrollo de determinados productos open source y dedican por tanto gente suya a contribuir en ellos.
En cualquier caso, todo esto supone una gran bofetada en la cara de la cúpula directiva de las empresas a las que se refiere este artículo.
Lo más triste es que las prácticas descritas son tan absurdas para el cliente como para el propio proveedor; al proveedor le suponen más esfuerzo del necesario y con ello una peor productividad y al cliente un mala calidad y con ello una hipoteca a futuro. Nadie gana y todos pierden, y al sector de las TIC en su conjunto se le hace daño.
¿Cómo entonces es posible que a estas alturas siga dándose en tantos casos?
Responder a esta pregunta con algo de rigor requiere un grado de conocimiento del funcionamiento interno de estas empresas y la relación con sus clientes que yo no tengo. No obstante, en el siguiente post intentaré hacer una pequeña aproximación a ello en base a las experiencias mías, de compañeros y de proveedores.
Mientras tanto, si algún lector amable se anima a ello, sería muy interesante conocer otras opiniones y experiencias.
[...] This post was mentioned on Twitter by gonreg, microlopez. microlopez said: “Deuda técnica”: la burbuja de las TIC http://wp.me/pEZYN-sf [...]
Muy bueno.
Pues la verdad es que este es un tema que creo que toca de lleno la fibra sensible de todos los que nos dedicamos a esto. Aun tratándose de un tema complejo al final creo que el principal causante es simplemente la profunda ignorancia sobre la naturaleza de los desarrollos de software por parte de los responsables de estas organizaciones. Esa ignorancia también está presente en los clientes y en general en buena parte de los afectados por este modo de hacer las cosas y esto contribuye a ocultar el problema. Me temo que la única salida es que esta burbuja estalle aunque pagarán justos por pecadores.
Excelente descripción de la situación. Cuantas veces me habré encontrado con barreras al intentar emplear frameworks o librerías para realizar determinadas tareas. No se puede se tan hipócrita como para pensar que un equipo de trabajo puede realizar utilidades mejores que Struts, Spring, Apache Commons Lang, y otras tantas, y encima querer que funcionen mejor.
Y algo muy importante,los desarrollos que suelen hacer las comunidades de desarrolladores suelen madurar infinitamente más rápido que los propios. Sólo hay que fijarse en la cantidad de usuarios que lo utilizan o prueban.
Todavía hay mucha gente que parece que quiere volver a inventar la rueda.
Porque el mundo informatico esta lleno de Ingenieros industriales, telecos, fisicos, matematicos, abogados, bibliotecarios en paro, publicistas, borrachos, duermevelas, abrazafarolas y no de INGENIEROS INFORMATICOS con COLEGIO
Vaya casualidad, el mundo del Open Source tambien esta lleno de Ingenieros industriales, telecos, fisicos, matematicos, abogados, bibliotecarios en paro, publicistas, borrachos.
O has visto por casualidad que te pidan estar colegiado para hacer tu aporte en la Fundacion Apache?
Tipico españolito mediocre que quiere armarse su propio territorio para luego pasar a ser un funcionario.
Las grupos de trabajo son buenos cuando hay buenos lideres y se basan en una “meritocracia”. Sos ingeniero y crees que sos muy superior a un abogado desarrollando software. Ok. Demostralo! Pero no pretendas ser mejor por “portación de título”…
Veo que te dedicas a la informatica y no eres informatico, ¿no?, Pues mira no puedes ser buen profesional de primeras por que te faltan conocimientos basicos como son arquitectura de computadore, ingenieria de software y un largo etc.
El problema de esto no es el intrusismo, que hay y mucho. Sino que en muchos caso el arquitecto de software, no es informatico sino teleco o fisico. Como va a diseñar una arquitectura de software un fisico!!! es alucinante, que va a utilizar el patrón un tren sale de barcelona a las tres y otro sale de madrid a la 1 donde se va a encontrar. O que pasa que ahora en fisica o en teleco se ve ingenieria del software o patrones de diseño.
como si todos los ingenieros informáticos supieran programar.
Menudas chapuzas tengo que arreglar dia a dia hechas por ingenieros informáticos presuntuosos que desconocen lo que significa la palabra: “pruebas”
buenas, soy Arquitecto de Software con mas de 10 años en el desarrollo de software, tanto a medida, como productos finales y por mi experiencia la raíz del problema es muy clara, por regla general lo clientes no tienen ni idea de lo que quieren y mucho menos no tienen ni idea de lo que es el software, y así dificilmente pueden tener criterios de calidad, ademas, tambien por regla general, los famosos “gestores”, “managers/minigers” y demás “jefecillos” no tienen ni idea de lo que es la ingeniería del software, que existen metodologías, patrones y buenas practicas, ya que la mayoría de estos roles están ocupados
por ingenieros industriales, telecos, economistas y demás profesionales que nunca han estudiado ingeniería del software y así dificlmente pueden tener criterios de calidad.
yo te cuento mi visión del asunto: cuando un cliente pone unos requisitos de pasta/tiempo y varias consultoras se pegan por el proyecto (generalmente bajándose los pantalones), poca calidad se puede esperar
es decir, el primer culpable es el cliente por querer plazos totalmente imposibles (si se quiere hacer bien, claro) y el segundo culpable es el proveedor por querer ganar a toda costa
luego, hay quien dice que uno de los objetivos de hacerlo mal es asegurarse que haya contratos para la mejora y/o arreglo de la primera chapuza, cosa que me resulta difícil de creer (pero no imposible)
en resumen, mejor asumimos que la deuda técnica ha venido para quedarse, y la tendremos que aguantar cual suegra tocapel…
¿Cuantos test de JUnit tiene el kernel de Linux?
No es que este encontra de probar, es que los casos de prueba hechos con JUnit (o similar) son muy poco productivos y detectan muy pocos errores para lo que cuesta hacerlos. Pero usar JUnit es una de esas cosas que hay que usar porque todo el mundo lo usa, si no eres mal profesional y, ademas, “¿es que no te parece bien que se pruebe la aplicacion?”.
Hombre, por favor. ¿Cuantos test de Junit tiene el kernel de Linux? Ninguno, JUnit es una API para automatizar test unitarios de código hecho en Java y el kernel de Linux está hecho en C.
La pregunta es ¿quién escribe el código kernel de Linux? Ya te digo yo que becarios contratados por cárnicas no.
Lo de que detectan muy pocos errores es directamente falso. Los test de JUnit no se escriben para detectar errores que ya se están produciendo. Eso es contraproductivo. Se escriben para asegurar tu código y evitar errores regresivos al introducir modificaciones en el mismo.
Por otro lado ¿Quién es el iluminado que dice que por el simple hecho de escribir tests automatizados no se deben probar las aplicaciones a manija?
Un poquito de por favor.
Pues mira, supongamos que tenemos un metodo que recibe un String. Una de esas cosas que tienen un monton de caracteres puestos en fila. Supongamos que el metodo le da la vuelta o, que se yo, da igual.
Entonces vas y la haces el caso de prueba, escribes un test que va bien, uno que provoca un error y, como eres un tio que sabe la de $deity, otro que le pasa un null.
Y te quedas tan ancho porque a partir de ahora puedes refactorizar traquilo.
Y pregunto yo haciendome el tonto: ¿y donde has probado la cadena vacia? ¿la que tiene una eñe? ¿la cedilla, la dieresis, los acentos? ¿las comillas de un tipo y otro? (el sqlinjection es un cabron) ¿el menot el mayor? (crosssitescripting, ya sabes) ¿la cadena que tiene espacios por delante, por detras, por delante y por detras, en medio? (he visto como desaparecian miles de buzones de correo por no probar eso) ¿la que tiene 50Mb de caracteres para desbordar el buffer?
¿Cuantas pruebas llevamos? ¿20? Ahora me vas a decir que escribes 20 casos para un metodo que recibe un string. Y si recibe dos strings, escribes 20 para uno, 20 para otro, mas las combinaciones.
Y yo me lo creo.
Seguro que eres de los que ha metido en un ant (mejor un maven que es mas chulo) un paso de lanzar junits, otro para pasar un clover para ver cobertura de pruebas, y todo eso lo ejecutas desde un hudson, envias correos cada noche con el informe de cobertura y te quedas tan ancho porque tienes una cobertura del 85 por ciento. Y miras por encima del hombro a los malos profesionales que no tienen ni puta idea porque no escriben casos de prueba y no tienen montada una infraestructura de integracion continua y extreme programming tan buena como la tuya.
Pero lo cierto es que tus casos de prueba dan risa porque no has probado ni algo tan basico como el sqlinjection. Y no lo has hecho porque escribir casos como es debido te llevaria cinco veces mas tiempo que el desarrollo en si, pero cuando alguien te lo recuerde siempre diras que el hacer test de junit denota profesionalidad y en ningun caso evita hacer pruebas, asi que, para no perder tiempo en hacer algo que no te evita hacer pruebas de verdad, escribes cuatro casos mal contados para cubrir el expediente y poder decir que TU eres bueno y los demas no tienen ni puta idea.
Un poquito de por favor.
Qué chorrada hacer tests con junit para validar Strings… $deity Zend inventó Zend_input y sus reglas para eso, lo que pasa que los javeros os aburrís y os inventáis religiones varias xD… es broma, quiero decir que para eso está el framework o librerías estándar.
¡Si hubiera más framework y menos chapuza, habría menos errores, pero también habría menos trabajo! Regocijémonos en la chapuza!
Buenas,
Corta el rollo que no he dicho nada de lo que comentas. Entré un poco a trapo por que no había leído nada tan desinformativo sobre el tema como lo que escribiste en mucho tiempo. Puedes ver mi post justo encima del tuyo. Ya he dicho que los programadores del kernel de Linux probablemente no necesiten ni código de pruebas ni metodología alguna. Yo evidentemente lo necesito por que no soy ningún crack.
El tema es ¿cómo haces tú para probar todos esos casos que comentas? Cuentanos tu fórmula por favor que si es mejor compro.
Cuando corriges un bug. ¿Cómo te aseguras que este no se vuelva a producir?
Y por último si te cuesta escribir una clase de JUnit desde dónde se use tu código o tus clases. ¿Cómo consigues usarlo en otro escenario o lo que es lo mismo en tu aplicación? ¿cómo consigues hacer código reutilizable?
Un saludo
El intrusismo es un problema considerable que tiende a difuminarse dado que un libro de patrones de diseño o de análisis de sistemas está al alcance de cualquier persona que haya programado. El problema de verdad es que todas estas empresas no dejan de ofertar becas para estudiantes de cuarto y quinto que saquen el trabajo, se cobre sus horas a precio de consultor senior y luego se disfrute de unos productos que se pueden describir como prácticas de laboratorio calificables, con las que la persona ha aprendido la nueva tecnología.
Estupendo post, de verdad. Nos debe hacer reflexionar a todos, clientes y proveedores. Mi empresa basa su actividad en soluciones de software libre, y nos beneficiamos de esa calidad en los procesos de las que hablas. Curiosamente, cuando aportamos módulos o conocimiento a la comunidad, estamos obligados a seguir esos criterios de calidad porque si no no se acepta dicha aportación, pero en el caso de proyectos para clientes no siempre podemos aplicar esos procedimientos. Más que un problema de dinero, que también lo es aunque somos conscientes de que un margen reducido en principio puede tener más beneficio en el medio plazo (productividad, calidad del resultado…), creo que tiene que ver con requerimientos de tiempo en muchos casos sin una justificación práctica. Con lo bien que funciona casi siempre el sentido común…
Hola a todos. Soy otro Arquitecto de Software limitado en muchas ocasiones por las reglas de otro Arquitecto en un cargo superior, quien, jutno con los directivos de la organización se quejan del risego que “implicaría” usar productos de software libre y es una regla para ellos que si un producto no lo ofrece una compañía comercial, no es un producto en el que se pueda confiar, pero andan tan alejados del tema técnico, concentrados en su plazos y cronogramas que quisiera ver su cara cuando supieran (y entendieran) que el 99% del software que producidos para ellos, se basa en software libre (librerías, programas, sistemas, etc)… Los culpables de esta burbuja siempre han sido y siempre serán los gerentes/directores de proyecto, etc complacientes con el usuario (que nunca sabe lo que quiere, lo que pide y lo que realmente le sirve) y explotadores de sus desarrolladores y analistas.
FInalmente, muchos (no todos, ojo) desarrolladores se conforman con lo que aprendieron en la universidad o en un curso, pero nunca se preocupan por actualizarse constantemente, por averiguar un término desconocido, por autoaprender y siempre buscar como hacer mejor las cosas, sin repetirlas.
En fin, es más predecible y tranquila la agricultura…
Es lo que mi profesor llama, “Informalidad” de los procesos empresariales, TI entra a sostener estos procesos mal diseñados desde siempre, la arquitectura suena como la solución a este problema….pero falta mucho para que se empieza a realizar a gran escala.
Alberto:
Al final del post dices “Responder a esta pregunta con algo de rigor requiere un grado de conocimiento del funcionamiento interno de estas empresas y la relación con sus clientes que yo no tengo.” Pues bien, yo creo tener ese conocimiento ya que he trabajado en estas empresas como desarrollador y arquitecto viendo una y otra vez lo que describes perfectamente en tu post. Me ha tomado mucho tiempo formar una teoría de por qué se da esto. Y puedo decirte que estoy convencido de que el principal problema es que los proyectos son lidereados por personas que no tienen conocimientos técnicos y los que desarrollan casi siempre son programadores jr. pero, ¿Por qué sucede esto? Mi teoría es que esto es el resultado de una cultura empresarial que trata de aplicar las mismas técnicas que usa comunmente en proyectos tradicionales, en proyectos de desarrollo, y aqui esto simplemente no funciona. He discutido esto recientemente en dos posts:
Por qué los managers y analistas ganan más que los programadores?
Ingeniería vs Artesanía (de Software)
[...] » noticia original [...]
Totalmente de acuerdo en el fondo, aunque matizaría los ejemplos que pones.
En mi experiencia, habiendome tocado mantener proyectos de multitud de empresas distintas, tanto la arquitectura por capas como el uso de logs sí son habituales. Los problemas vienen porque muchas veces no se usan bien, por desconocimiento, inexperiencia, prisas, cambios continuos y todo esto permitido por la falta de supervisión.
También coincido en que para rematar la faena no se hacen buenas pruebas y se deja que sea el cliente el que encuentre los fallos… absurdo, ¿no?
Tienes toda la razón con el matiz de los logs. Con no usarlos no me refería a que no exitan en muchos casos no se cuida lo más mínimo la información a volcar, no hay ningún diseño “activo” de usar bien el mecanismo de excepciones y aprovecharlo entre otras cosas, para generar buena información en los logs, a pesar del gran valor que aporta ante las incidencias.
Aprovecho tu comentario y edito esta parte para que quede claro el matiz.
Me ha gustado mucho el artículo, y tengo mis propias teorías al respecto (aunque ni de lejos tan informadas); pero no puedo evitar hacer una pequeña corrección: ¿Linux “Torwalds”? ¿Es alguien distinto al Linux Torvalds (http://es.wikipedia.org/wiki/Linus_Torvalds) que conocemos todos?
Gracias por la pista. Corrijo el gambazo.
Por cierto, aprovecho para pedir que se mantengan las formas, no caben insultos, alusiones personales, etc. En la sección de Contacto se habla de ello. Están llegando comentarios con salidas de tono que no son tolerables.
Gracias a todos.
Incluso gente con conocimientos puesta de “manager” o lo que sea puede resultar ser un problema. La práctica de tener al jefe contento, pasando por prometer plazos imposibles y decir que “sí” a cualquier paja mental que se le pase por la cabeza sin protestar elimina cualquier ventaja derivada del conocimiento técnico.
Esto lo he dicho muchas veces: “avisé hace 1 año de que esto acabaría pasando, pero como había que sacarlo cuanto antes no valían retrasos de dos semanas para hacerlo en condiciones. Ahora tenemos a los del helpdesk inyectándose tila, los jefes cabreados porque nos quedamos en lo mínimo y retrasos en el resto de proyectos por tener que volver a dedicar recursos indispensables”.
¿Cómo entonces es posible que a estas alturas siga dándose en tantos casos?
FACIL
Es lo que el cliente quiere: un proyecto BARATO y acabado en el menor tiempo posible….
La TIC lo hacen PERDIENDO DINERO y luego recuperan y tienen ganancias de los contratos de mantenimiento de la mierda que han hecho…
Si pagas con platanos contratas monos.
Buenos días a todos.
Me sumo a la discusión, muy acertada por otra parte, de aquello que podríamos llamar nuestro via crucis particular, la ingeniería de software como tal.
Quería referirme previamente al intrusismo. Señores, todos conocemos telecos, físicos y matemáticos con un nivel de programación muy superior a muchos ingenieros informáticos, seamos honestos.
Me pregunto si uno aprende a programar en la universidad, o son las miles de horas que dedicamos al margen. Particularmente lo tengo claro, es lo segundo …
Adoptar estándares de desarrollo, tal como se aplican en proyectos opensource, resulta tremendamente complicado en el mundo empresarial, donde prima lo inmediato, la planificación es siempre escasa y el talento se reprime supuestamente en pos de la simplicidad y el calendario, que finalmente se convierte en un paradójico sobrecoste y retraso.
Cuántos de nosotros hemos tenido que justificar una y otra vez la adopción de estándares altamente asumidos por la industria con nulos resultados, para que al final, el vendedor de humo de turno, proveniente de una consultora de alto nivel, termine colando a la empresa un modelo infumable que será adaptado con calzador ante unas necesidades inexistentes.
El problema, a mi modo de ver, parte de la falta de formación y conocimiento de los estándares, y de la aplicación masiva del principio de Peter en las corporaciones. Sinceramente, una pena
Hay un gran tapón de gente con menor formación relacionada o poco autodidacta en los puestos de mando que contagia esta mala praxis y la cual ha de ser subsanada por toda una generación más joven y preparada: ya sean universitarios o de módulos de informática, y sobretodo que no sigan estos malos hábitos cuando lleguen a puestos de mando.
También añadiría que hay grandes carencias de comunicación y escasas reuniones con sentido, y falta de sentido de responsabilidad sobre todo en este país.
Yo siempre lo he visto en el software libre. Te encuentras todo tipo de burradas. La excepción son cuatro aplicaciones conocidas como Linux o Apache, pero 4 o 5 excepciones no hacen un conjunto completo.
No hay que confundir los objetivos de una empresa, al dividirla por este criterio tenemos:
1) Empresa que busca ganar dinero desarrollando software: deberá preocuparse por la deuda técnica y muchas otra cosas para lograr un margen debido a la relación entre el precio del software que vende (más o menos en relación al valor del software que percibe su cliente) y el coste para realizarlo.
2) Empresa que busca ganar dinero asumiendo el riesgo laboral y reclutando gente: en este caso la deuda técnica no le interesa, eso es un riesgo de su cliente. Su negocio es encontrar gente “vendible” (poner muchas siglas en un CV), tratar de que le cueste “poco” (aquí entran los becarios) y lograr que el cliente los acepte. Ellos solo actúan como un buffer para que el cliente pueda presentar una balance con unos costes fijos bajos y el resto variables y además es una pseudo protección legal (por ej. queda feo que BBVA despida 500 programadores)
Bueno, estoy bastante de acuerdo con el artículo, pero creo que se centra demasiado en criticar temas técnicos cuando, desde mi punto de vista, no es el núcleo del problema. Aparte de que algunos puntos son discutibles. Por ejemplo, como se ha comentado, el uso de los logs no es tan marginal; sí que se suelen usar bastante.
Creo que Héctor lo ha explicado muy bien, es básicamente una cuestión de avaricia. La avidez por conseguir dinero fresco con que compensar las cuentas del año, acaba imponiéndose a la prudencia y a la sabiduría que nos dicta que a la larga ganas más haciendo bien las cosas. En España no hay cultura de pensar a largo plazo (ignoro si en otros países sí). Los problemas de un año vista no importa mientras se
“arreglen” los de hoy. Paradójicamente, sólo preocupa ganar los 10K euros del mes que viene, sin pensar que eso nos podrá provocar a la larga perder 20K, 50K, o más.
Ese es uno de los grandes factores. El otro es que no se sabe trabajar en equipo. Pero por equipo no me refiero al grupito de los 2 o 3 picateclas más el programador senior que les guía (este pequeño grupito humano sí suele entenderse bien), sino al conjunto de las partes implicadas, desde el último programador al propio usuario final, pasando por la persona de contacto del cliente, el consultor, el analista, etc. Cada cual se preocupa sólo de “salvar su culo”, por así decirlo, y no de trabajar todos juntos en hacer algo bien parido. Hay muchos momentos en los que uno siente tentaciones de poner juntos simplemente al usuario final y al programador, y que los demás se vayan a liarla a otra parte.
Bueno, como programador que soy en una de estas carnicerías creo poder hablar con un poco de propiedad al haber trabajado en un par de ellas.
Para empezar estoy de acuerdo con muchos de vosotros en que los gerentes, los mandamases suelen venir de empresariales y enchufismo y no de un tecnico, no digo ya informático. Gente que sólo le importa sacar más y más al mismo esfuerzo, pero no se mejora la máquina (que es como ellos nos ven , maquinas que dedican unas horas para venderlas, no venden el producto , venden horas de trabajo) sino que le piden más horas. Si no se sebe hacer una cosa en una hora, no se va a saber hacer en dos, no dan formación, piden horas extras gratis, hechan al que vale y se quedan con el becario porque es más barato, y total solo venden horas , etc
Actualmente donde trabajo , la empresa no hace que tener beneficios, a base de echar a gente y querer que la gente que queda supla el trabajo de la que ha hechado, el usuario pide cosas casi imposibles, que en un plazo de tiempo este hecho el programa, y muchas veces ni poniendo todos los recursos que quieras puede ser asi, de forma que se crea una aplicacion-fachada que parece que funciona, hace lo básico , te muestra datos por pantalla. pero que a la que le das dos veces a un mismo boton todo deja de funcionar.
Todo es un cúmulo de despropositos que sobrevive por la necesidad del mantenimiento de la información.
Si estubiera obligado demostrar una calidad a un colegio de informáticos (lease expertos) bajo pena de multa y recompensacion al afectado, otro gallo cantaría. Ahora con el programa ya te estan vendiendo un ‘mantenimiento’, en principio para pequeños cambios que el usuario decidiera hacer, no para hacer que el programa funcione. Me he encontrado casos que el equipo de mantenimiento ha acabado de construir el programa pues se habían dejado cosas por implementar y lo vendían como fallos, no como trabajo no hecho.
La realidad es la siguiente: No es que las empresas no sepan hacerlo bien, es que no hay incentivo ninguno para hacerlo así.
Cuando el modelo de negocio se basa en que hoy subcontrato a uno y mañana a otro, pues no merece la pena hacerlo bien para que después llegue otro y se aproveche de lo bien que lo dejé yo, es mejor hacer la gran chapuza y así me aseguro que el que mejor lo maneja soy yo, y si además dentro de poco me voy a quedar sin el trabajo, mejor hacerlo corriendo y con el mínimo esfuerzo, el que venga detrás que arree.
Por otra parte, hecerlo bien reduce horas de mantenimiento… pero si el cliente me paga por horas de servicio y personal… hmmm…. ya sabéis por donde voy.
El problema es del propio modelo de negocio y el propio modelo de subcontratación, que prima la chapuza, simplememente porque es más rentable para la empresa que provee el servicio (otra cosa sería para el clientem, pero él no es quien hace el trabajo).
Esto es la pura realidad, el que quiera calidad, que se vaya de España. Trste pero cierto.
Yo creo que que hay muchos sitios donde se hace codigo espageti, donde se cambian los requerimientos el ultimo dia, donde se presupuesta por lo bajo, donde se acortan los tiempo, etc. Esos sitios son malos por definicion y en eso estamos todos de acuerdo.
Pero yo creo que hay otros sitios que son incluso peores, y generalmente, son los sitios que se ponen a si mismos como ejemplo. Son esos sitios donde se sigue a pies juntillas a Martin Fowler, donde se usan las ultimas siglas que estan de moda en la blogosfera. Esos sitios donde se montan servidores de integracion continua que lanzan un monton de cosas.
Es como desarrollar con cromos: “yo tengo hudson y ant”, “pues yo tengo jira y maven, y mi maven gana a tu ant”. Es desarrollar pensando mas en como va a quedar el powerpoint que explica el producto que en el producto en si. Es estupendo para la carrera del arquitecto, pero para el proyecto…
POr ejemplo, cuando yo empece a desarrollar, era impensable subir a produccion un acceso a base de datos cuyo sql no hubiera pasado su preceptivo explain. Ahora, no solo somos pocos los que recordamos lo que es un explain, si no que el mero hecho de tener que escribir una sentencia sql se considera un atraso y se finiquita el tema con un “eso es codigo boilerplate, mejor usar hibernate que nos quita el *aburrimiento* de escribir sql”.
Escribir objetos normales era suicidarse profesionalmente, hasta que alguien rebautizo los objetos de toda la vida como “pojos” y escribio un “Pojos in action”. Entonces ya pudieron a volver a escribirse objetos como se habia hecho siempre…
En fin, que el desarrollo esta mal, pero no hay que hacer mucho caso de los que se ponen como ejemplo y te sueltan una retahila de siglas.
PD: Yo se de un sitio donde los servidores se paran por falta de espacio en disco porque un creyente en la programacion orientada a aspectos dijo “no escribais trazas, *que no lo vais a saber hacer bien*, mejor usaremos un aspecto que escribira la traza de manera automatica con la entrada y salida de cada metodo”. Como se llaman muchos metodos, se escriben muchas trazas, asi que se llenan los discos y se queddan sin espacio para ficheros intermedios, compilar jsps….
Sólo una referencia que responde a tu pregunta:
en forma de comic de dilbert
saludos y buen post
Aquí todos estamos en una cosa de acuerdo, no se invierte en calidad.
Yo he estado en una gran “factoria de software” unos cuantos años. Se valoraba más el jefe que pegase 2 gritos y que los demás drugos le tuviesen miedo, al jefe que te ayudaba y te motivaba a trabajar mejor.
Era muy triste que cuando te llenaban el proyecto con becarios(que todos lo hemos sido) y pidieras un día para formarlos te dijeran ¡Comoooooooo! estas tont@. Y tu te quedarás con la cara de WTF pensando van a ser unos cuantos meses muuuuy largos. Yo por ejemplo me gane muchas broncas por formar gente, al principio pasaban de mí. Pero luego cuando “molestas” empiezan a degradarte profesionalmente.
Luego el tema formación, siempre veia q se la daban al jefecillo de turno que dejaba el libro en cualquier cajon. Luego el programador de turno tenia q tirar de google porq no tenia a nadie quien le explicase nada.
En España se valora más callar y currar 12 horas.
Veo que casi todos sufrimos males parecidos, de una u otra forma, da igual si uno viene de las charcuteras o en diambula en el cliente final.
Siguiendo con algunas reflexiones que acabo de leer, me viene a la mente como esta misma mañana, en una de esas divertidísimas reuniones tan productivas se trataba de explicar al jefe de turno las implicaciones que derivan de un diseño arquitectónico concreto. Tras varias semanas intentando explicarle que sin una reunión de trabajo serie donde se explique el funcionamiento persé, nos estamos dedicando a filosofar sobre lo divino y lo humano, y lo que más me molesta, perdiendo un tiempo que no tenemos. Conclusión: lo que en una hora de trabajo intenso quedaría resuelto, a día de hoy lleva ya unas 5 o 6 en reuniones absurdas dando vueltas a conceptos abstractos, para no entrar al trapo de la cuestión. Ya os adelanto, que seguramente en la próxima volveremos a debatir lo mismo otra vez, eso sí, facturando al cliente … sin comentarios
[...] » noticia original [...]
Yo trabajo para la Administración y he podido observar cada uno de los sitios es un mundo diferente, con sus propias normas y procedimientos, digámoslo alto y claro. Soy Ingeniero Técnico Informático, cursando Económicas, llevo 10 años en el sector y actualmente trabajo para un Ministerio (JSF 2, Spring 3, Alfresco 3, etc…). Nada más llegar, mi jefe me dijo: haz esto y lo quiero en una semana ¿para qué un período de adaptación? ¿para que un análisis funcional y orgánico? La única excusa es que como cobraba mucho ¿?, debía ser druida, mago, etc… y debía adivinarlo todo, incluso la interfaz de usuario. Señores, por favor, ya está bien de echarle la culpa a la “crisis” (que ya no es financiera, sino política, al menos desde que le vendimos la deuda a China) y preocupémonos de hacer las cosas con un mínimo de calidad. Yo, de momento, he acordado con ellos rebajarme el sueldo y que se olviden un poco de mi hasta que encuentre otro cliente, porque ya estoy muy quemado en esta profesión y mi único aliciente es hacer las cosas bien, no rápido. Quien piense que es mejor pescar barato en río revuelto, conmigo que no cuente… Saludos.
Información Bitacoras.com…
Valora en Bitacoras.com: Gracias a un este simpático artículo en Barrapunto y un tweet de @juankipe me he topado estos días atrás con el concepto de la “deuda técnica“, el cual desconocía y me hizo gracia por las paralelas con los recientes aconteci…..
Cuando los clientes no quieran un producto para mañana en vez de cuando lo quieran cuando esté bien, empezaremos hablar… cierre de requisitos y esas cosas, no se puede desarrollar con dos meses de margen y pensar que va salir bien.
Te veo quemado es un sector complicado en el que se hacen muchas horas, ánimo.
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, …
[Nota: párrafo suprimido por vulnerar las normas para los comentarios, contiene críticas y acusaciones dirigidas a personas e instituciones concretas. Véase sección de Blog & Contacto ]
Creo que me has interpretado mal en una parte del artículo, cuando te refieres a las “buenas arquitecturas de diseño, prácticas y calidad, supongan al proveedor mas esfuerzo y peor productividad”. Por supuesto que son esenciales y que la productividad va de la mano con ellas. Decir eso estaría totalmente en contradicción con el resto del artículo.
Gracias Alberto por la corrección, perdoname es que estoy calentito con el asunto.
[...] este artículo completo sobre el concepto de “deuda técnica“, en el blog de Microlópez, porque describe de una manera asombrosamente real un problema que lastran muchas de las empresas [...]
Sinceramente creo que hay aspectos fundamentales. Uno de ellos ya comentado: Los propios clientes basan sus estrategias tan solo en el coste económico de los desarrollos. No tienen en cuenta factores como calidad y mantenibilidad que garantizan éxito a largo plazo. Seguimos con la cultura del pelotazo.
Ademas, los sistemas y desarrollos no están diseñados o dirigidos por profesionales. Es normal el intrusismo de los propios clientes y/o personal no cualificado en la definición de las arquitecturas a utilizar, los lenguajes de programación utilizados, el hardware a implantar y demás aspectos técnicos que desconocen. Y nosotros lo consentimos. ¿Imagináis comentarle a un medico que nos haga un TAC para un dolor de muelas?
Otro aspecto fundamental es el tema de plazos. Vienen marcados por los aspectos económicos de la oferta, a los cuales hay que adaptarse cueste lo que cueste. Obviamente, a costa de calidad. ¿Cuando van a tener en cuenta la opinión de los profesionales a la hora de desarrollar las ofertas las empresas proveedoras de servicios?
No quiero sacar balones fuera del campo. La desidia de alguno de nosotros, que simplemente sacan su trabajo adelante, también es condenable. Es necesario que adoptemos un compromiso real por realizar nuestro trabajo con la mayor calidad posible.
Hola a todos,
una metáfora bastante buena, en general. Los ingenieros tenemos el síndrome Dilbert, no entendemos a esta clase de mánagers.
Otros puntos se han tomado más a la ligera, en mi opinión, parece como si las certificaciones CMMI no sirvieran para nada. Es cierto que no son la garantía absoluta de nada, pero si el porcentaje de empresas TIC que las tienen fuera mayor del 1% del total (cifras españolas) otro gallo nos cantaría.
En fin, esperemos que el cambio de cultura hacia la calidad y la innovación sea una ola imparable aunque lenta. Los que creemos en ello, nos tenemos que dar ánimos y seguir en la brecha.
desde mi punto de vista la principal causa es la falta de arquitectos en las empresas que tengan una visión completa de las necesidades dela empresa y de los proyectos en curso. Muchas veces le pedimos a los proveedores lo que no hemos querido o podido implantar en nuestra empresa: Una arquitectura de Desarrollo completa que tenga en cuenta el ciclo de vida y el gobierno de la solución. Me refiero a cosas como un marco de desarrollo, componentes reutilizables, desarrollo que faciliten la operación de las aplicaciones ( logs bien usadoe, etc.)separación de reglas de negocio, etc.
Y en el desarrollo en sí hace falta utilizar una metodología que tenga en cuenta cosas como la calidad de software, la metodología de pruebas, etc.
Normalmente quién tiene esto son empresas que viven del desarrollo de Software como IBM, ORACLE, Microsoft,etc. Es más, ee el Software abierto esto se aplica en los desarrollos que empujan las empresas que viven del software.
Y luego está la presión de la empresa por reducir el coste del proyecto: Bajame el precio y el tiempo…..
Y por último ( aunque no menos importante) la no inversión de los proveedores en la formación de la gente y en el uso de metodologías que mejoren la calidad del software
[...] nos encontremos en otra burbuja como la inmobiliaria y estemos sin quererlo generando una deuda tecnológica que en algún momento dejara de ser sostenible para empresas, desarrolladores y clientes. Dentro de [...]
[...] poseía ya una gran deuda técnica sobre sus desarrollos de Ruby y unos servidores de frontal corriendo un número fijo de hilos que [...]
[...] poseía ya una gran deuda técnica sobre sus desarrollos de Ruby y unos servidores de frontal corriendo un número fijo de hilos que [...]
[...] nos encontremos en otra burbuja como la inmobiliaria y estemos sin quererlo generando una deuda tecnológica que en algún momento dejara de ser sostenible para empresas, desarrolladores y clientes. Dentro de [...]