Descargar artículo

mordecki.com
Artículo
Por Daniel Mordecki
05 de octubre de 2003
Las técnicas y herramientas de programación diseñadas para correr en equipos con 64kb
de RAM y 30MB de disco se siguen usando hoy, muchas veces sin cuestionarse su
vigencia. No es un problema de moda, sino de la necesidad de generar sistemas más
eficientes y rentables.
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 ENIAC1 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.
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.
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
no es bueno es que la
Hoy en día el mayor costo, tanto en tiempo como en recursos y dinero,
filosofía de la escasez
lo lleva la mano de obra que desarrolla, implementa y soporta los
subsista 20 años después
que sus causas más
sistemas. Los equipos, que antaño representaban la mayor parte de los
profundas ya no existen
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.
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.
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.
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
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.