«Quizá fue una hecatombe de esperanzas
un derrumbe de algún modo previsto»
... Y es que cuando se piensa en Ingeniería de Software y en los procesos afines todo parece anunciado y dispuesto para el desastre. Una mezcla de amor por el análisis y de desamor por el desorden humano impulsa a creer que no hay manera de salir de las trampas autoimpuestas a través de la industria, y que sólo se puede prosperar alejándose de los esquemas administrativos rígidos que suelen mezclar la juventud de tecnócratas ansiosos por mejorar su nivel de vida y los prejuicios de administradores incapaces de innovar, todos seguidos por un rebaño de programadores sin mucha intención de lanzar juicios ni de resistir el ritmo que exige la ineficiente tarea de construir software, finalmente todo sirve para aprender. Lo que se olvida es que existe la necesidad misma de olvidar lo que se ha hecho en el pasado para permanecer vigentes, así gran parte del esfuerzo será perdido.
Ya hay varios juicios que se pueden hacer a la industria, muchos de ellos evidenciados únicamente fuera de los ambientes tecnocráticos. El lenguaje no solo construye software sino que es la base que construye a los constructores de software, los seres humanos, y allí se evidencian varios vicios, uno de ellos es el de la metáfora antropomórfica que hace a los ingenieros hablar de las cosas como si fueran personas, refiriéndose a clases, programas, procesos y sistemas como seres animados con los caprichos de comportamiento que da la naturaleza. Un efecto sintomático es el de llamar bugs a los errores de programación, señalando al programa y no al equipo humano detrás de él como responsable de los fallos que se van manifestando, entonces hay que reparar a ese «man» y no tiene relevancia revalorar el método.
Pero hay más, la animosidad del software libre no parece haber considerado en sus cálculos la proliferación de soluciones divergentes para problemas similares. Miles de posibles aplicaciones, entre comerciales y libres, resolviendo los mismos problemas complican el panorama de aprendizaje para los ingenieros, que deben utilizar cerca de la mitad de su tiempo productivo aprendiendo las funcionalidades, opciones y configuraciones de las herramientas, mientras la solución que se busca construir se va aplazando o va consumiendo el tiempo libre de los ingenieros, que pese a ellos mismos siguen siendo, de algún modo, personas, casi seres humanos con criterio propio.
La anarquía ha hecho de las suyas en la industria. Para resolverlo conviene no dejar que sea el mercado el que tome las riendas como en otras cosas de la vida, pero tampoco se puede dejar que sea aleatorio el comportamiento de las herramientas. Puntos como la imposición de estándares de la ISO o recomendaciones ITU o cualquier otra directiva son insuficientes, no solo porque hay disparidad y multiplicidad de opciones a la hora de elegir una guía de estandarización, sino que cada una de las organizaciones parece tener múltiples soluciones y estándares para cada uno de los problemas. Demasiada libertad sigue siendo anárquica.
El panorama es, en realidad, aterrador. Para enfrentar los temores que produce la anarquía tecnológica baste con pensar que no hay nada lo suficientemente difícil, porque finalmente todo ha sido construido por humanos, el problema suele reducirse a contar o no con una buena fuente de información. La receta funciona cuando se sostiene la decisión para el resto de la vida, pero tan pronto se pasa de un proyecto a otro, se pasa también de un régimen dictatorial a otro mientras el ingeniero, en cualquiera de sus roles, sigue en problemas, y las herramientas siguen su propia evolución anárquica. La evolución tecnológica conjunta aporta un poco al problema, pero no de manera contundente porque cada paquete de soluciones se puede evolucionar aprovechando el conocimiento previo con el que se resolvían los antiguos problemas, siempre que sus creadores no decidan hacer borrón y cuenta nueva debido a una mala planeación inicial, la complicación está cuando se cambia el paquete de soluciones y se debe pelear de nuevo con la herramienta.
El resultado, desde el punto de vista de la gestión, es que los proyectos requieres más puntos de control en la medida en que son menos relevantes las soluciones propuestas, en parte por la lucha contra estándares y herramientas reaplicados, y en parte por el facilismo con que se afronta a un problema conocido esperando que todas sus fases se repitan; en consecuencia, suponiendo que se sabe qué va a pasar, se ejerce más control sobre su construcción. Al mismo tiempo los proyectos requieren de menor control cuando más innovación poseen, cuando se afrontan problemas desconocidos y cuando evolucionan basados en las mismas herramientas, con cambios graduales y sin la terrible necesidad de empezar de cero a resolver un problema que ya había sido resuelto. Éstas afirmaciones son categóricas y son consecuencia de una Ingeniería de Software que ha evolucionado contra natura.
«... Ah pero mi tristeza solo tuvo un sentido
todas mis intuiciones se asomaron
para verme sufrir
y por cierto me vieron»
De momento las reglas están impuestas aunque sean incoherentes, y es con estas reglas con las que se debe jugar. Sin embargo los guías espirituales de la Ingeniería de Software deberían pensar que tal vez «la culpa es de uno cuando no enamora y no de los pretextos ni del tiempo». Sin esta conciencia los proyectos de software seguirán siendo, estadísticamente, un total fracaso.
Comentarios