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.

El PAe se describe a sí mismo como “un centro de referencia que sea puerta de entrada para toda la información sobre situación, desarrollo, análisis, novedades e iniciativas que surgen en torno a la Administración, contenidos y servicios de fuentes muy diversas, convirtiéndose en el agregador de opinión, motor de participación y dinamización de toda la Comunidad con intereses en sus diferentes áreas”.

En ese sentido, “la Dirección General para el Impulso de la Administración Electrónica ha coordinado el reto de unificar y homogeneizar en un único punto la información de las Administraciones Públicas en esta materia.”

Los siguientes objetivos que se anuncian son los siguientes:

• Trabajar conjuntamente con todas las Administraciones Públicas, de forma que se generen relaciones dirigidas a incrementar el valor que cada una de ellas proporciona en materia de Administración electrónica.
• Ser referente en Administración electrónica, introduciendo nuevas formas de participación tanto interna como externa, fomentando la retroalimentación y el acercamiento de la Administración Pública a los interesados.
• Consolidar el PAe como punto único de atención para los ciudadanos, empresas y Administraciones Públicas, coordinando los esfuerzos de contenidos, tecnología y personas hacia la consecución del punto único de información de Administración electrónica.

Personalmente me parece una iniciativa magnífica por muchas razones:

En primer lugar porque actualmente el campo de la Administración electrónica es muy amplio (servicios disponibles, marco legal, tecnología relacionada, etc.) y la información sobre la misma se encuentra tan fragmentada que un portal como éste era absolutamente necesario, un punto de acceso único a través del cual se pueda llegar a cualquier cosa importante relacionada con la Administración electrónica.

Igualmente me parece muy acertado que el enfoque sea integral contando con las demás Administraciones cosa que, por otra parte, entiendo que actualmente no puede ser concebida de otro modo, aunque siempre tengo reservas en las iniciativas que dependen de la colaboración e iniciativa activa de un elevado número de partes.

Actualmente la fragmentación en las diferentes administraciones de servicios y productos de plataformas de  servicios de Administración electrónica es enorme. Aún con las reservas de no haber hecho ningún análisis en profundidad, me da la sensación de que la fragmentación es excesiva y síntoma de duplicación de esfuerzo. Esperemos por tanto que esta iniciativa con el tiempo sea también capaz de aportar mayor racionalidad en este terreno, aunque lógicamente no va a ser ninguna píldora mágica sin la colaboración de todos responsables respectivos.

Sin embargo, el mero hecho de su existencia puede ser un gran acicate si se consigue que sea un portal vivo con el protagonismo que se merece, ya que simplemente no se pueda ignorar y quien lo haga correrá el riesgo de quedar en evidencia.

Si además consigue que sus herramientas colaborativas sean potentes y fáciles de usar creo que puede dar realmente sus frutos. Para ello nada mejor que inspirarse en los modelos consolidados en contextos comparables que ya se sabe que funcionan muy bien, como lo son, por ejemplo, las redes sociales y las comunidades abiertas de desarrollo como la Apache Software Foundation.

En ese sentido el PAe cuenta ya con algunos elementos como eColabora para el acceso a la información, discutir y participar en la vida pública, diseñado de un modo que se inspira en las redes sociales y la Forja del CTT, que añade al CTT un nuevo entorno de desarrollo colaborativo para aplicaciones de las administraciones públicas en el que pueden participar activamente administraciones, empresas y particulares. Cuenta con funcionalidades de descargas, documentos, novedades, foros, registros de incidencias, bugs, sugerencias, encuestas, distribución de tareas, listas de distribución de correo y gestión del código fuente basado en la herramienta Subversion, que es la referencia en las comunidades abiertas de desarrollo antes mencionadas. Se integran además forjas afines como las de Andalucía, Cataluña y Extremadura, e incluso la forja europea OSOR.

Por último quisiera mencionar también la Biblioteca del PAe, algo que responde también a otro terreno muy fragmentado: el de la documentación sobre la Administración electrónica. Resulta un dolor buscar en Internet, por ejemplo, documentación para formarse, cosa que en su momento inspiró la creación del manual que se publica en este blog. Aquí la biblioteca del PAe puede aportar mucho.

No obstante, hay algunas cosas que echo de menos:

Por una parte, creo que sería muy conveniente una mayor división temática, sobre todo orientada a la formación de base del personal administrativo que, por lo general, sigue aún muy pez en esto de la Administración electrónica. Ya se emplean tags (palabras clave), pero creo que sería muy bueno incluir además categorías de búsqueda prefijadas que diferencien publicaciones tan dispares como planes departamentales de documentos didácticos.

En la parte general del portal ya se emplea para ello una nube de etiquetas para buscar, lo cual resulta muy práctico. Creo que con trasladar esto mismo al buscador documental ya se lograría una gran mejora.

Otro tema que me ha llamado la atención es que la biblioteca sólo incluye los documentos recogidos y/o publicados por el propio portal, creo que iría con el espíritu de los tiempos incluir una referencia temática de publicaciones tanto gratuitas como comerciales ajenas al propio portal y la Administración. Hay mucho material muy interesante y especializado, tanto comercial como gratuito que merece ser referenciado, como por ejemplo, las publicaciones de Bartolomé Borrego en el ámbito de la gestión tributaria electrónica o cosas tan valiosas como la documentación del curso de Administración electrónica que se ha publicado recientemente en el blog de Félix Serrano.

Esto último me sugiere también una idea: incluir una referencia y/o pequeño apartado dedicado a la blogosfera pública.

Tenemos la suerte de disponer en España de blogosfera pública muy potente que ya lleva funcionando unos cuantos años y cuya madurez creo que está sobradamente demostrada. No obstante, lo que veo en la Administración es que, aunque ya cuenta con un buen número de seguidores interesados, aún no se conoce entre los funcionarios y personal afín a lo público en la medida que se merece.

Una referencia o un apartado que hable de la blogosfera sería en ese sentido un paso lógico con un claro beneficio para ambas partes: ampliar los contenidos oficiales con muchos y diversos contenidos de calidad y aportar una mayor difusión a la blogosfera pública actual, cosa que sin duda se merece.