Todo es poco

Así nació la informática, con equipos que ocupaban manzanas enteras, para procesar apenas unas operaciones aritméticas sencillas. Durante muchos años, a pesar de las mejoras significativas, las computadoras siguieron siendo equipos enormes, costosos y con recursos extremadamente escasos: un procesador demasiado lento, un disco demasiado pequeño, y una cantidad de memoria mínima. Es así que en el año 79 u 80, encontrar equipos que daban soporte a un centenar de terminales con 64kb de RAM y 30MB de disco era algo todavía frecuente.

En el año 79 u 80, encontrar equipos que daban soporte a un centenar de terminales con 64kb de RAM y 30MB de disco era algo todavía frecuente.

Los logros de esos años son mayúsculos y hoy nos preguntamos con asombro: ¿como hacían? ¿Cómo procesaban las facturas, llevaban los inventarios, pagaban los sueldos, con esas máquinas que hoy parecen ridículas? Los algoritmos lucen una elegancia y un ingenio sin límites. Los modelos de datos y las técnicas asociadas a ellos destilan un clase digna de los mayores elogios. En general, durante esos años se sentaron las bases de la informática moderna, bases que siguen hoy vigentes.

Pero desde la ENIAC [1] hasta el 80 habían pasado 35 años. 35 años en los que la forja de la teoría y la práctica informática tuvo un convidado de piedra: construir las aplicaciones que dieran soporte a los procesos de negocios y a las investigaciones científicas extrayendo la mayor potencia de cada ciclo de procesador, de cada bit de memoria. Los sistemas operativos, los lenguajes de programación, la teoría de construcción de aplicaciones y la cultura de toda la industria estaba permeada de norte a sur y de este a oeste por la obsesión de conseguir programas que se adaptaran mejor a los recursos escasos de los sistemas. Cualquier programador sabía «rematar» un programa en assembler para ahorrar ciclos de procesador, consideraba detalladamente el almacenamiento de sus variables en memoria, de modo de ahorrar la mayor cantidad de bytes y de acelerar al máximo los accesos a memoria que el programa realizara. Esta práctica ininterrumpida de más de tres decenios constituyó una verdadera filosofía de trabajo: la filosofía de la escasez.

La realidad del derroche

La realidad de hoy es muy distinta. La mayoría aplastante de la capacidad de procesamiento del mundo está la mayoría del tiempo ociosa, sin contar el tiempo en que está apagada.

Los procesadores tienen una instrucción llamada NOP (No OPeration) que el sistema operativo ejecuta cuando no tiene nada para hacer. En todo momento se están ejecutando en el mundo cientos de miles de trillones de operaciones NOP. Los discos por su parte están llenos de programas y archivos que no tenemos idea de para qué sirven, (muchas veces no sabemos siquiera quién los instaló) pero que no desinstalamos por el miedo a que luego de la desinstalación la máquina deje de funcionar. Tal vez la memoria no esté tan holgada, pero de todos modos los equipos de hoy en día tienen muchas veces sólo para las operaciones de video más memoria que lo que hace 20 años se usaba para dar soporte a 100 usuarios, y además es 1000 veces más rápida y 1000 veces más barata.

La mayoría aplastante de la capacidad de procesamiento del mundo está la mayoría del tiempo ociosa, sin contar el tiempo en que está apagada.

Las consecuencias

Que los equipos pongan a disposición de los usuarios una enorme capacidad de procesamiento es algo realmente bueno. Que las bases de la informática estén fundadas en una teoría sólida, probada una y otra vez en la práctica, es también muy bueno. Lo que no es bueno es que la filosofía de la escasez subsista 20 años después que sus causas más profundas ya no existen.

Más equipos menos programadores

Hoy en día el mayor costo, tanto en tiempo como en recursos y dinero, lo lleva la mano de obra que desarrolla, implementa y soporta los sistemas. Los equipos, que antaño representaban la mayor parte de los costos informáticos, hoy son un costo relativamente pequeños en comparación a los costos de mano de obra. Pero la filosofía de la escasez sigue predominando, invirtiendo las prioridades: se desarrolla el software con herramientas nacidas de esa filosofía y con metodologías propias de esa filosofía. Programar en Cobol o RPG por ejemplo, no tiene «per se» nada de malo: tanto Cobol como RPG son lenguajes robustos, ampliamente probados y muy eficientes sin duda. Pero nacieron bajo la filosofía de la escasez, y a ella se deben. Hoy es necesario dotar a los programadores y analistas de herramientas de más alto nivel, que les permitan desarrollar programas más sofisticados en menos tiempo. Probablemente estas herramientas de más alto nivel terminen generando código Cobol, C o RPG, que luego será compilado y ejecutado en el equipo.

No es bueno es que la filosofía de la escasez subsista 20 años después que sus causas más profundas ya no existen.

Es cierto que el código escrito directamente es en general más eficiente que el generado por herramientas de alto nivel. Pero para ello deben cumplirse algunas condiciones:

• tener programadores de gran nivel
• que dichos programadores cuenten con una larga experiencia en el uso del lenguaje de programación
• que dispongan de tiempo para optimizar su código.

Mientras tanto un programador utilizando una herramienta de más alto nivel generará un código menos eficiente, pero lo hará sensiblemente más rápido y con menos bugs. Por supuesto que con herramientas de alto nivel se pueden desarrollar programas pésimos, pero esto es algo que se puede hacer también con herramientas de bajo nivel. Para que la comparación tenga sentido, pensemos en ambos casos en desarrolladores de buen nivel, con un conocimiento razonable de la herramienta que usan.

La diferencia de rendimiento se compensa con equipos más poderosos: así de sencillo. Es más económico, tiene menos errores y es mucho más fácil y barato de mantener.

La diferencia de rendimiento se compensa con equipos más poderosos: así de sencillo. Es más económico, tiene menos errores y es mucho más fácil y barato de mantener.

Ciclos de desarrollo más cortos

La filosofía de la escasez nació y se desarrollo en un tiempo donde valía la pena pasar un mes refinando el código para que fuera posible ejecutarlo en los mínimos 64KB del equipo. No solo valía la pena: era imprescindible porque no había más que 64KB.

Hoy en día, un proyecto de dos años es para una empresa de 500 empleados un megaproyecto. Para una de 50 empleados es sencillamente impensable

También los procesos que se atacaban se mantenían relativamente estables en el tiempo: la contabilidad, el pago de los salarios o el manejo de inventarios son procesos relativamente estáticos, que se mantienen en sus pilares fundamentales incambiados a lo largo de muchos años dentro de una empresa.

Hace 20 o 30 años que la informatización de un proceso implicara un proyecto de dos años era algo común. Y otra vez lo mismo: las herramientas, las técnicas, las metodologías estaban concebidas sobre esta base. Hoy en día, un proyecto de dos años es para una empresa de 500 empleados un megaproyecto. Para una de 50 empleados es sencillamente impensable. El «time to market» de la mayoría de las implementaciones se mide en meses, no en años, y muchos de ellos en semanas.

Invertir neuronas en problemas con más retorno

El resultado de la filosofía de la escasez puede resumirse en la siguiente frase: «Siguiendo los dictados de la filosofía de la escasez se pone foco en problemas con bajo retorno, y se deja de lado la oportunidad de trabajar sobre problemas con mayor retorno».

Sacar horas de trabajo de la mejor gente en optimizar el código para correrlo en equipos pequeños, es un derroche de talento. Sin duda, esa esfuerzo sería mucho más rentable si se dedicara a desarrollar software más sofisticado, con mejores interacciones con los usuarios, que abarque más procesos de la empresa, que llegue más lejos, hasta clientes, proveedores y distribuidores, que permita transformar los torrentes de datos en armas para tomar decisiones más informadas.

Vencer la inercia

En realidad, lo único que sostiene en pie a la filosofía de la escasez es la inercia: no es más rentable, no es más adecuada a la realidad, no es más eficiente, no produce más satisfacción ni en los clientes, ni en los usuarios, ni en los propios programadores. Pero el argumento de que hace más de 50 años que lo venimos haciendo así parece ser más fuerte que la razón.

Vencer a la inercia que sostiene en pie a la filosofía de la escasez es un imperativo que generará en su empresa sistemas mejor adaptados a las necesidades de los negocios que a las necesidades de los equipos.

Vencer a la inercia que sostiene en pie a la filosofía de la escasez es un imperativo que generará en su empresa sistemas mejor adaptados a las necesidades de los negocios que a las necesidades de los equipos
 

_____________________________

[1] ENIAC (Electronic Numerical Integrator and Computer) es considerada la primera computadora electrónica digital. Fue construida por la Marina de los Estados Unidos, para realizar cálculos de Balística, durante la segunda guerra mundial. Comenzó a operar en octubre de 1945.