archivo

Archivos Mensuales: septiembre 2010

El danés Bjarne Stroustrup fue el padre del C++ y es catedrático en la Universidad A&M de Texas. Su trayectoria le permitió ser reconocido hace dos décadas como uno de los doce mejores científicos jóvenes de Estados Unidos según la revista Fortune y a recibir desde entonces diferentes premios y reconocimientos.

Sobre la evolución en la complejidad y funcionalidades de los dispositivos móviles comentó lo siguiente (traducción libre): “Siempre he deseado que mi ordenador fuese tan fácil de utilizar como mi teléfono. Mi deseo se ha convertido en realidad porque ya no sé como utilizar mi teléfono”.

Detrás de esta ironía, se encuentra el hecho de que realmente los dispositivos móviles han ido adquiriendo progresivamente un mayor número de funciones y posibilidades que los han convertido en un ordenador, con una ventaja sobre estos por su tamaño y también con inconvenientes por el mismo motivo.

Anuncios

No hace mucho escribí un artículo denominado “Un sistema de información sin mantenimiento” en el que especifico las características que debe tener una aplicación para no requerir tareas de mantenimiento continuo y lo que podría ocurrir en el caso de que necesitándolo no se pongan a su disposición los recursos que precisa.

Dentro de muy poquito uno de los sistemas de información que gestiono se queda sin presupuesto para mantenimiento. Es una aplicación grande, con muchos usuarios, con bastante uso, que afecta a varios departamentos, que está desarrollada en la tecnología prácticamente obsoleta, que tiene ya casi siete años de puesta en producción (aunque su concepción y análisis se remonta prácticamente cuatro años atrás) y que a lo largo de este tiempo ha sufrido numerosas modificaciones y ampliaciones funcionales, correcciones, etc… incrementándose su complejidad de forma paulatina.

¿Deberían haber sido siete años suficientes para dejar medianamente estable el sistema? La respuesta es que en condiciones normales sí, pero esas no han sido las circunstancias que han rodeado al mismo, ¿qué lo podíamos haber hecho mejor? También, y soy consciente de ello.

¿Por qué se queda sin presupuesto? Principalmente (y lo pongo por encima de la crisis económica, aunque de no existir ésta se hubiese encontrado financiación) porque los gestores de los departamentos a los que presta servicio no ven crítico que no haya dinero para mantenimiento, en unos casos porque probablemente no terminen de verle la utilidad al sistema y en otros porque en el fondo piensan que se encontrará una solución por parte de informática para que el sistema no quede sin soporte. No voy a entrar a juzgar esto, ya que cada cual tiene que hacer frente con sus presupuestos a sus áreas de gestión y nadie mejor que ellos saben dónde deben gastar e invertir.

Como miembro del departamento de desarrollo todo este asunto me podría dar un poco igual ya que sería en todo caso el departamento de explotación el que tendría que hacer frente a las demandas de los usuarios en cualquiera de los niveles de atención a usuarios ya que desde desarrollo no se podría dar respuesta a las incidencias y peticiones que nos escalen, la cual quedarían sin resolver de forma indefinida, debiéndose buscar alternativas en el programa para sortearlas (a veces será posible, otras no).

Sin embargo, cuando uno ha trabajado en un sistema tanto tiempo, le ha dedicado tanto esfuerzo y ha sufrido muchísimo desgaste, no puede abandonarlo como tal, por lo que en previsión de lo que podía pasar (y era algo que se veía desde hace prácticamente un par de años ya que el presupuesto ha ido disminuyendo paulatinamente hasta quedar en la actualidad y hasta dentro de muy poco, una cantidad simbólica) he intentado buscar alternativas para que el impacto sea el menor posible (muchas de ellas no salieron).

Entre ellas (y es de las primeras que se logró) es que se distinguiera claramente las tareas que correspondían al CAU de las tareas de desarrollo, por lo que el presupuesto de atención a usuarios de la aplicación se desvió a la bolsa general de atención a usuarios de mi organización. Esto que puede parecer lógico y que ya está implantado en mi organización, estaba todavía en fase muy embrionaria cuando se llevó a efecto. De esta forma la atención a usuarios de primer y segundo nivel estaba garantizada y además con unos niveles de calidad muy buenos porque el equipo de personas que está detrás también lo es.

Una vez que la atención a usuarios estaba cubierta quedaba otra parte y es tener la posibilidad de dar respuesta ante incidencias en el uso del sistema que necesiten la participación del departamento de desarrollo así como al mayor número de peticiones relacionadas con alguna modificación funcional.

Sobre esto he tenido mucho menos margen de maniobra y los resultados, como es lógico, no han podido ser muy significativos. Dado que una parte de la aplicación está construida en Java (una parte muy pequeña) y algunos de los componentes que utiliza (y que son parte de la aplicación) también lo están, dada la precariedad de los recursos económicos de mantenimiento del sistema, se tomó la decisión de que entrasen dentro del proyecto de mantenimiento global de sistemas de información desarrollados en Java, por lo que por lo menos una parte de la aplicación (aunque mínima) estaba cubierta ante posibles incidencias.

¿Qué pasa con el resto (que es casi todo)? Pues en estos últimos meses en colaboración con el CAU y con el soporte todavía vigente de la aplicación, se han desarrollado funcionalidades en el área de administración del sistema para incrementar la casuística de incidencias que puede atender el CAU. También se ha trabajado en aquellas funcionalidades de la aplicación que presentan más problemas. Todo esto sigue siendo insuficiente para poder prestar un servicio de calidad a los usuarios cuando nos quedemos sin mantenimiento pero siempre será mejor que nada.

¿Qué pasará? Todavía tengo la esperanza de que se consiga algo de financiación que nos permita alargar el soporte algunos meses más, pero en el caso de que no se llegue a ella, probablemente algunas de las consecuencias indicadas en el artículo al que hacía referencia en el primer párrafo se producirán, teniendo cada vez una comunidad de usuarios más molesta que dará lugar a una disminución paulatina en el uso de la herramienta, así como en la calidad de las tareas que se realizan a través de ella.

Vivimos en una roca, dentro de uno de los cientos de miles de millones de sistemas que conforman una galaxia mediana como es la Vía Láctea. Esa es nuestra realidad, en comparación con el universo tal vez un grano de arena en el desierto tenga más relevancia que nosotros.

Por tanto cada uno de nosotros somos pequeñas gotas de agua en este inmenso océano del que todavía se desconocen la mayoría de sus secretos.

Las evidencias por tanto nos invitan a pensar que cada uno de nosotros no somos el centro de nada que no seamos nosotros mismos y cualquier otra apreciación es errónea. Nada gira alrededor nuestra, más allá de nuestros pensamientos, nuestros sentimientos, todo el conjunto de cualidades que hacen que seamos como somos.

Pero eso pasa con respecto al universo externo, es decir, todo aquello que no somos nosotros y que se rige por distintas leyes. En nuestro universo, dentro de nosotros mismos, somos infinitos y si en él existe equilibrio nuestra relación con el exterior será mucho más fluida.

Se codifica, se construye la aplicación, pero en demasiadas ocasiones se tiene en cuenta como fin único la entrega del proyecto, dejando al margen o dedicándole menos importancia a una programación pensando en futuros mantenimientos.

La dificultad de los mantenimientos depende de muchos factores y algunos de ellos están por encima en importancia de una codificación clara y de calidad, como por ejemplo la búsqueda de una alta cohesión y un bajo acoplamiento, lo cual no debería ser una excusa para olvidarnos de este asunto ya que no se trata solo de que se pueda comprender lo que se ha programado (que no es poco) sino que un código poco cuidado probablemente influirá en una mayor complejidad ciclomática de la aplicación (además de a la mayoría de las variables que determinan la deuda técnica de la aplicación) dificultando, en consecuencia, a la mantenibilidad.

Generalmente nos solemos acordar de todo esto cuando toca realizar el mantenimiento del sistema de información y nos encontramos con que la forma en que se ha codificado hace que se requiera un mayor esfuerzo y en consecuencia coste. Por este motivo importa y mucho como se codifica.

El problema de todo esto es que resulta complicado detectar este tipo de problemas en tiempo de desarrollo ya que obliga a estar encima y revisar el código, lo que puede hacer que casi cueste más el collar que el perro. Por tanto, tenemos que utilizar otras estrategias que faciliten la localización de estos problemas, como es por ejemplo estudiar variables que se pueden incrementar indirectamente por una mala programación (se puede realizar una revisión periódica de las métricas que devuelve Sonar) y complementarlo, si es posible, con la revisión, también periódica, de una muestra de clases de la aplicación.

Siendo realista, veo complicado que una empresa de desarrollo, salvo que las deficiencias encontradas en el proceso de verificación interno sean serias, se pongan a rehacer a módulos ya codificados, pero por lo menos si se aplican estas políticas se puede reconducir la tendencia en el desarrollo y que el proyecto se encuentre dentro de unos umbrales de calidad aceptables (los cuales en algunos casos podrán ser exigidos y verificados por el cliente y provocar un rechazo en la entrega y la consiguiente necesidad de refactorizar partes de la aplicación lo cual se volverá en contra del proveedor ya que tendrá que sufrir en sus carnes las consecuencias de unas malas prácticas.

Martin Fowler es un importante y reconocido autor especialista en ingeniería del software y en el proceso de desarrollo (particularmente en el campo de la refactorización) el cual ya he tenido la oportunidad de citar en un artículo sobre una regla de CheckStyle que no comprendía su significado.

Steve C. McConnell es otro reputadísimo autor y especialista en ingeniería del software, tanto es así, que durante años fue considerado junto a Linus Torvalds y Bill Gates unas de las personas más influyentes en el negocio del desarrollo de software. En la actualidad posee una empresa llamada Construx Software que se dedica a consultoría y formación sobre buenas prácticas en desarrollo de software.

Ambos autores son responsables de las siguientes citas relacionadas con la comprensión del código:

Martin Fowler (traducción libre): “Cualquiera puede escribir código que un ordenador pueda entender. Los buenos programadores son aquellos que escriben código que los humanos puedan entender”.

Steve McConnell (traducción libre): “El buen código es su mejor documentación. Cuando vayas a escribir un comentario, pregúntate, ¿cómo puedo mejorar el código para que este comentario no sea necesario?”.

Sobre este tema ya publiqué una cita que se atribuye a Martin Golding en unos casos y a John F. Woods en otros que complementa perfectamente a éstas.

Como he comentado en otras ocasiones, hacer las cosas bien, tarde o temprano, marca la diferencia.

Cuando hablo de enfrentamiento no me estoy refiriendo a tener opiniones distintas o que en el transcurso de una reunión o en el contenido de un correo haya una palabra más alta que otra.

El desarrollo de software es un negocio y por tanto detrás de él hay dinero, carreras profesionales, intereses personales, etc… y no se puede esperar que en un entorno como ese todo sea siempre paz y tranquilidad. Este mundillo es así y ese tipo de problemas los terminarás percibiendo de una u otra manera independientemente del puesto que ocupes en tu organización, ya que incluso estando recién incorporado a tu puesto de trabajo y sin experiencia te puede tocar un proyecto con unos plazo de entrega digamos que complicados.

No obstante a los problemas normales de funcionamiento dentro de una organización (plazos, trabajo en equipo, etc…) hay que sumar aquellos derivados de trabajar con el cliente y con sus usuarios.

Habrá proyectos que vayan bien, ¿por qué no?, esos casos existen, pero también habrá otros donde vengan mal dadas, pudiendo ser los motivos de lo más variopinto (mala estimación temporal y/o económica del proyecto, requisitos funcionales cambiantes, equipos improductivos, errores en el proceso de desarrollo, etc…).

Cuando el proyecto vaya mal las posibilidades de choques con el cliente incrementan casi exponencialmente ya que si se llega a este punto quiere decir que el proyecto está en pérdidas o tiene todas las papeletas para estarlo. En estos casos se tratará por parte del proveedor de intentar reenfocar el proyecto de alguna manera con el objeto de que la cuantía de las perdidas no se dispare, pero el cliente, sobre todo si considera que no ha sido el responsable máximo de la situación, tratará de que el proyecto vaya hacia donde cree que debe ir (pudiendo ser este destino y el del proveedor discordantes y en algunos casos, opuestos).

Cuando surge el conflicto hay que evitar el enfrentamiento con el cliente, más tarde cuando finalice el proyecto puedes tomar la decisión (o tu empresa) de no volver a trabajar más con él (antes de tomar una decisión de este tipo hay que valorar lo más objetivamente posible, cuáles han sido los problemas que han existido en el proyecto y la responsabilidad de los mismos), pero un enfrentamiento con un proyecto no finalizado no arregla nada y pone más barreras entre cliente y proveedor que serán motivo de mayores costes. Ante el problema, negociación, mejor una mala negociación que un buen enfrentamiento (en el primer caso por lo menos puedes conseguir algo, en el segundo se llegará a que las cosas vayan a peor).

Los resultados de la negociación deben quedar por escrito y aprobados por las distintas partes que han participado en la misma. Lo mismo una negociación concreta no soluciona los problemas del proyecto, pero nadie dijo que no se pudiera negociar más de una vez cuando los asuntos que se traten sean distintos a los que se hayan negociado anteriormente o bien las circunstancias hayan cambiado.

Que habrá ocasiones en que las cosas no se puedan arreglar por las buenas o por las medios buenas, no lo niego, pero por lo menos es necesario intentarlo.

Muchas veces se plantean las aplicaciones como un lugar donde simplemente los usuarios graban datos (extiéndase esto a generar documentos o a sacar una serie de informes más o menos básicos).

El planteamiento en sí no es erróneo ya que cualquier software que se desarrolle para realizar mantenimiento de datos siempre me va a parecer mejor que cualquiera hecho por un usuario para realizar esa tarea y no quiero con esto restarle el más mínimo valor a esas soluciones ofimáticas, ya que a muchos les permite sacar adelante el trabajo del día a día.

Son varios los inconvenientes que plantean, me centraré en dos (aunque no hay que obviar otros, como es el mantenimiento de datos de carácter personal en ficheros que no cumplen los requisitos establecidos por la Ley o la posibilidad de pérdidas de información si los archivos no se encuentran ubicados en espacios donde se apliquen copias de seguridad):

– Este tipo de soluciones no siguen una normalización de la información, lo que provoca que la explotación de la misma resulte compleja, es decir, puedes encontrar lo que estás buscando, pero extraer otro tipo de conclusiones sobre ellas es complicado. Esto es un problema inherente a la extrema flexibilidad que ofrecen este tipo de herramientas y a que el uso que se le suele dar a las mismas es muy superficial (depósito de datos organizado de una determinada manera).

– Muchas veces este tipo de alternativas son como una caja B de las aplicaciones informáticas, donde se almacena información que el programa no contempla o bien se utiliza esta estrategia por resultarles más sencillo mantener el dato de esta manera. Esto plantea múltiples inconvenientes, ya que dará lugar más que posiblemente a una falta de coherencia en los datos, es decir, en la aplicación principal y en las “no oficiales” una misma entidad puede tener información distinta, ¿cuál es la buena?.

Este artículo no trata de criticar estas soluciones, sino de intentar exponer una de las causas que llevan a los usuarios a las mismas:

Tal vez no sea la causa más importante de la proliferación de soluciones basadas en herramientas ofimáticas, pero sí es una que da lugar a la aparición de cajas B y no es otra que el desarrollo de aplicaciones que simplemente se encargan de permitir grabarle datos. Eso ya lo tienen con su hoja de cálculo o con su base de datos ofimática y además lo pueden hacer más rápido y fácil (de hecho, como ya he dicho en otras ocasiones nada puede competir contra este tipo de herramientas salvo que las alternativas ofrezcan utilidades que ahorre trabajo) . En su lugar se les ha puesto un programa que les hace lo mismo, solo que la productividad con él disminuye ya que se tarda más en grabar los datos y es más complicado y además se encuentran con errores que no siempre se arreglan tan pronto como desearían.

Las aplicaciones no solo hay que pensarlas como almacén de datos, sino también como una colección de utilidades que realmente proporcionen un valor añadido al que las usa, si el usuario nota esa diferencia no pondrá tanto inconveniente en utilizar una herramienta más compleja y que les obliga a trabajar de una determinada manera, se trata de un “tu me das, yo doy”. Cuando se rompe el equilibrio, los usuarios (salvo instrucciones expresas que obliguen al uso de la aplicación) tenderán a los caminos alternativos (no todos, porque la ruptura del equilibrio no se produce para todos en el mismo sitio y a la vez)

Muchas veces nos enredamos en un problema e invertimos mucho tiempo y esfuerzo intentando encontrar una solución, hasta tal punto que nos empeñamos en resolverlo sin mirar el reloj y sintiéndonos cada vez más presionados por nosotros mismos.

Precisamente, cuando llegamos al punto en que nos da coraje no encontrar la respuesta es cuando pienso que hay que recoger los bártulos y volver a intentarlo mañana u otro día. Aunque creamos que no, nuestra mente seguirá trabajando en el asunto y probablemente cuando lo volvamos a intentar se nos ocurrirán cosas nuevas que no llegamos a probar en el intento anterior.

Otro aspecto que es importante considerar es la importancia de aquello que pretendemos arreglar y que no damos con la clave y los trabajos que podríamos estar haciendo y que tenemos parados porque nuestra atención está en ese otro problema. Salvo que sea algo de extrema urgencia y que requiera que tengamos todos nuestros sentidos en ello (si somos objetivos, pocas tareas merecen ese calificativo), no hay que olvidar que tenemos otras tareas, algunas de las cuales además pueden ser cuello de botella para que otras personas puedan continuar con su trabajo.