Anerdipro Blog

Reproducimos 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 de nuestro sector, el de las TIC.
Es un problema, además, que puede afectarnos de manera muy preocupante en un futuro a corto-medio plazo, así que, aunque es una lectura larga, es muy recomendable y constructiva.

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 elesfuerzo 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 granLeopoldo Abadía en el vídeo de abajo, todo esto resulta en definitiva en unaacumulació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: unavisió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 financierossobre 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 ypatrones 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:

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.