ANOTACIÓN 2012 Serie 1 No 3: 4 de febrero, 2012

ANTECEDENTES HISTÓRICOS, primera parte: LOGDIAL:   

LOGDIAL – CNRC, OTTAWA, CANADÁ. 1982-1983

          En mi consciencia científica, la semilla paradigmática que engendró a VIPERS comienza en un laboratorio en el sótano del Consejo Nacional de Investigación del Canadá o “CNRC” en el verano del 1982, semanas antes de mi 19 cumpleaños. Bajo la tutela de mi padre yo llevaba casi un año trabajando en mi nueva profesión como programador-analista, Había programado varios diseños suyos, incluyendo un sistemas denominado “OBAL” (“Overton Basic Assembly Language”) que hacía simulacros de programas de ordenador escritos en una versión elemental del lenguaje elemental de computación conocido como un “assembly language” – un “lenguaje ensamblador”. Un “lenguaje ensamblador” (o “assembler”) es un lenguaje de programación de bajo nivel para los computadores, y OBAL era un programa que mostraba visualmente a los alumnos estudiando assembler cómo se ejecutan en la computadora los pasos de las instrucciones de sus programas escritas en ese lenguaje de programación básico a la vez que se ejecutaban las instrucciones del programa mismo. (En términos de computación lo que había programado con OBAL era un “interpretador” de programas, es decir, un programa que a su vez toma las instrucciones de otro y lo “interpreta”, va ejerciendo las instrucciones decodificando los mandos de las mismas. El interpretador más común es el sistema de programación llamado BASIC, universalmente conocido y en muchos casos muy, muy sofisticado y nada ‘básico’. Más sobre eso en adelante.)

          En el CNRC tuve un proyecto mucho más complicado del que jamás había tenido, un proyecto que no solamente lanzaría mi carrera como programador-analista y también como analista de sistemas, sino que cambiaria mi forma de pensar y de estar en el mundo. Comenzó como un proyecto de mi padre que él mismo llevaba concibiendo desde sus días como ingeniero de computación y sistemas en ITT, España un par de años antes. Se trataba de una metodología para hacer simulacros visuales de diseños de sistemas de información, de programas de computación en general, que comenzaba con una innovación ya en la representación diagramática.

          Los diagramas de la metodología de mi padre combinaban el flujo de la data, es decir, la transformación de la data (o ‘información’) a través del programa – junto con el flujo de la ejecución del programa mismo, o sea, del orden de la secuencia de los de las instrucciones. Tradicionalmente flujo de data y flujo de ejecución se representaban por separado y en representaciones diagramáticas diferentes y no integradas. De ahí que se tenía “Flow Charts” para representar el flujo de la lógica de las instrucciones por un lado, y “Data Flow Diagrams”, para captar las transformaciones de la data o información a través del sistema por su parte. El diseño completo de un sistema de información se podría lograr por primera vez en una sola representación que integraba tanto la información o data misma como las instrucciones que la transformaban.

          La segunda gran innovación, que surgía como resultado de la primera, era la idea de poder hacer un simulacro computarizado del diseño diagramático.  Es difícil explicar para alguien que no haya trabajado en el campo de la informática, sobre todo en sistemas con más de 50,000 líneas de código de programación – los denominados “proyectos grandes” –  la revolución metodológica y tecnológica que supondría esta innovación.  Pocos pueden comprender el estado horrendo del diseño, de la implementación, de la corroboración (comprobación), y del mantenimiento (ajustes a los sistemas de acuerdo a los cambios requeridos para el cliente o usuario) en el campo del software. Mientras que el desarrollo del software en general ha sido un éxito – eso es obvio, no precisa de mayor confirmación que la experiencia empírica, estamos rodeados de programas que funcionan o al menos nos sirven –  el costo de ese éxito es insólito. El estado de desarrollo de software – programas para los ordenadores o computadores – es tremendamente costoso debido a muchos, muchos factores. Gran parte del problema viene a ser en función de la dificultad de poder hacer buenas cotizaciones. Todo programador experimentado aprende que el tiempo verdadero de lo que tarda su proyecto es de DOS a TRES veces lo que originalmente cotizó.  Y aun así, muchos proyectos de centenares de millones de dólares USA acaban siendo eliminados por completo antes de poder llegar a su conclusión.  

          Más de dos décadas después de haber comenzado ese proyecto en el CNRC de Ottawa, Canadá,  la industria del software sigue estando repleta de casos representativos de fracasos multimillonarios. Creo que un artículo de una página web dedicado precisamente al estudio de problemas y fracasos de software lo capta perfectamente:

15 de mayo 2006

La larga, triste historia del fracaso de proyectos de software

Del artículo de la IEEE “Por qué el software falla”[1]:

El octubre pasado, por ejemplo, el gigante minorista de alimentos británico “J Sainsbury” tuvo que cancelar su inversión de $ 526.000.000  EE.UU. en un sistema automatizado de gestión de la cadena de suministro. La mercancía se estaba quedan atrapada en los depósitos y almacenes  de la compañía  y no llegaban a entregarse en  muchas de sus tiendas.  Sainsbury se vio obligado a contratar alrededor de 3.000 empleados adicionales para abastecer sus estanterías de forma manual.

Este es sólo la última de  una larga historia,  triste de proyectos  [de Software]  que salieron mal. La mayoría de los expertos en TI {Tecnología de la Información} están de acuerdo en que estos fallos se producen con mucha más frecuencia de lo que deberían. Es más, los fracasos son universalmente libres de prejuicios: se producen en todos los países, hasta en las grandes empresas y en las pequeñas, en las organizaciones comerciales, sin fines de lucro y las gubernamentales, y sin importar el estado o la reputación. Los costes empresariales y sociales de estos fracasos, en términos de dólares  de los contribuyentes y pérdidas de los accionistas, así como las inversiones que no se pueden hacer, son ya bien entrados los miles de millones de dólares al año.

El problema empeora a medida que se hace ubicuo. Este año, las organizaciones y los gobiernos se gastaron un estimado de $ 1 billón {un trillón americano} en hardware, software y servicios en todo el mundo. De los proyectos de TI que se inician de un 5 a un 15 por ciento será abandonado antes o poco después de la entrega como totalmente inadecuados. Muchos otros se entregarán  tarde y por encima del presupuesto o que requerirán una  remodelación masiva. Pocos proyectos de TI, en otras palabras, son verdaderamente exitosos.[2]

          Cualquier innovación que permita un desarrollo más detallado del diseño y una confirmación de su validez –  en términos tanto de cumplimiento de los requisitos del usuario – y de su eficacia –  y de si funciona o no, supondría una revolución en el campo. 

          Y así mismo comenzaron los problemas en nuestro propio proyecto: el diseño original de mi padre, una vez codificado en el lenguaje de programación NATAL II – creado en ese mismo laboratorio – no funcionó. Después de revisarme a mismo media docena de veces para asegurarme de que no había sido error mío, mi padre y yo ambos dimos un repaso al código de programación para ver si el error era mío en la programación o suyo en el diseño: efectivamente era un error de diseño. En retrospectiva era de prever puesto que el diseño mismo del programa estaba en la metodología de “Logic Data Diagrams” que por su parte no se había desarrollado lo suficiente para ser aplicado en un proyecto de esa complejidad. Es decir, la metodología de diseño diagramático no estaba a un nivel de usarse para diseñarse a sí misma. No se logró dar en por qué el diseño no funcionaba, así que dando muestras de quizás una capacidad o adquirida o innata o ambas para el análisis y desarrollo de sistemas, le dije a mi padre, “explícame en palabras lo que quieres que haga el programa, y yo lo programaré” – dicho y hecho. A partir de entonces se convirtió en mi proyecto heredado.

          El “tropiezo” inicial con el diseño fue una señal muy importante de las muchas innovaciones imprescindibles que se precisarían para que el proyecto tuviera éxito a largo plazo. Empecé a descubrir problemas con la metodología misma, o al menos con uno de los principios fundamentales: la idea de que un diseño efectivo pudiera hacerse a un nivel abstracto sin entrar en detalles. Ante lo errada de esa premisa hice un cambio fundamental en el concepto metodológico, decidiendo que en realidad lo que se precisaba no era una herramienta para hacer una SIMULACIÓN de diseños a un nivel abstracto para luego entregarle al programador y que codificara – tradujera en código de lenguaje de computación a mano – sino un lenguaje para una EJECUCIÓN  del diseño y después hacer la traducción automática al lenguaje, convirtiendo de esa forma el diseño en el programa –  es decir, el mapa se convierte en el terreno. Así fue como se pasó de la idea de un simulador para un diseño diagramático a alto nivel se pasó a lo que denominé “LOGDIAL” de LOGic-data DIAgram Language”. LOGDIAL no era simplemente un lenguaje de programación diagramático, sino un ambiente que regulaba la formación del diseño de acuerdo a reglas y principios para evitar ciertos errores típicos de programación que después se convierten en pesadillas a la hora de la verificación del sistema.

          Durante casi dos años continuó el desarrollo de sucesivas versiones de LOGDIAL dando demostraciones a altos funcionarios de empresas locales de software en la región de Ottawa, o lo que se llama el “valle del silicón del Canadá” por la concentración de empresas de computación similar al “valle del silicón” del norte de California.  La meta era lograr una versión de LOGDIAL capaz de poder representar un diseño tan elaborado de cualquier programa que luego se traduciría, automáticamente, en los lenguajes de programación de la época, y conseguir un inversionista que patrocinara el esfuerzo.  Cada presentación en el laboratorio a ejecutivos y expertos generaba una serie de comentarios y crítica que yo luego integraba para mejorar el producto y demostrar las mejorías en la siguiente versión.  

          El acceso a las instalaciones del CNRC en Ottawa no era para un tiempo indefinido y se logró lo que se prometió a cambio de su uso: un prototipo funcional que demostrara el poder del lenguaje de programación NATAL II, creación de ese laboratorio a gran costo del gobierno canadiense pero que nunca logró despegar en el mercado. Pero nuestras expectativas de lograr un inversionista que aportara el capital necesario para un desarrollo completo y comercial del producto nunca se lograrían.

          ¿Por qué? Por dos motivos. Una fue que, mi habilidad ‘natural’ para la programación aparte, me faltaba mucho conocimiento técnico necesario para crear una versión comercial, conocimiento relacionado, por ejemplo, a la implementación de programas como sistemas operativos y compiladores, conocimiento que no lograría obtener hasta pocos años más tarde en Queen’s University donde, aunque me licenciara en Estudios Ibero-Latinoamericanos, obtendría una concentración en ciencias de la informática (precisamente en pos del conocimiento necesario para desarrollar lo que para aquel entonces sería APEX). Por otra parte, la extrema novedad del producto y la naturaleza conservadora del canadiense (cuyo símbolo nacional es el castor) siempre ocasionaba la misma respuesta: “cuando tenga una versión comercial avísennos”. 

LOGDIAL – CADMICS AUTOMATION/MONTREAL, 1983 – 85

          Mi carrera de programador/analista me llevaría a un contrato con la gigante corporativa “Hydro-Quebec”, una de las empresas hidroeléctricas más grandes del planeta.  Como resultado del proyecto me trasladé a vivir en Montreal, donde residí durante un total de dos años aproximadamente. Terminado el proyecto con Hydro Quebec, CADMICS Automation, la empresa de mi padre y mía, consiguió algo de capital bajo un incentivo gubernamental de deducción de impuestos por inversión en proyectos de pequeña industria. Se implemento una nueva serie de prototipos en un sistema de Hewlett Packard usando su lenguaje de programación BASIC. Hubo avances en el prototipo, pero nunca se llegaría a la creación de una versión comercial antes de que los fondos se evaporaran.

          Pero hubo algo que me llevaba royendo desde una exhibición  que hice en un congreso de software en Ottawa, un comentario que me hizo un miembro del público del extranjero – alemán o suizo quizás – cuando describí las funciones que queríamos implementar en LOGDIAL para hacerlo compatible con los lenguajes de programación actuales: “¿Para qué limitarse a eso? ¿Ya que es algo nuevo, por qué no hacer algo completamente radical y totalmente nuevo?” Precisamente para ese tipo de retroalimentación era bueno exponerse a la crítica – práctica que continuo hasta la fecha con compartiendo mis libros en progreso con mis lectores, convirtiendo la autoría en un proceso dinámico. Mi respuesta en el momento fue algo así, “para encajar mejor con la tecnología actual,” pero su punto era valido – bien valido. ¿Por qué no? Una, porque no se nos había ocurrido, pero con la sugerencia ya sería más que suficiente. Dos, para ello habría que cambiar la idea de raíz, incluso modificando la estructura y el concepto de los diagramas mismos: ya no sería LOGDIAL. Y esa idea dio lugar a APEX – “Automated Programming EXpert system.”

Se continuará.

---

[1] http://spectrum.ieee.org/computing/software/why-software-fails

[2] http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html (Traducción propia.)