La filosofía de la escasez

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

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

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.

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 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 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.

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 filosofía de la escasez subsista 20 años después que sus causas más profundas ya no existen

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.

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:

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.

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

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.

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
 

_____________________
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.

 

 

Artículo

 

 

 

 

mordecki.com

 

 

 

Descargas

descargar Pdf Descargar artículo
 (PDF - 100 KB)

Valoraciones

Calificacion promedio 4

20 valoraciones

Su opinión:

Excelente

Muy bueno

Bueno

Aceptable

Regular

Malo

Muy malo

¡Suscríbase!

Reciba una notificación cuando se incorpora un artículo
Más información

Usabilidad, y estrategia en Internet

white_spacer

Descargas

descargar Pdf Descargar artículo
 (PDF - 100 KB)

Comentar

Nombre:

Email:

Comentario:white_spacer

Escriba la letra J

white_spacer

Comentarios

Ronald Sequeira Anchía
23 de Setiembre de 2008white_spacer
Me parece que los sistemas actuales lo que les falta es una depuración de los programadores y no de los lenguajes.
Antes desarrollabamos aplicaciones completas con Clipper, Fox o Foxpro, que a la fecha todavía funcionan en muchas compañias, cuando esas empresas quieren dar el salto ( y algunas veces es para atrás) a sistemas más modernos es común oir las quejas de los usuarios que tenemos el sistema caido o que el programa hizo lo que quiso y no saben como repararlo. Que quede claro que no estoy en contra de las nuevas tecnologías ya que tambien he dsarrollado aplicaciones en Oracle, Power Builder y he incursionado en el mundo de .Net y de C-Sharp, pero todavía no he visto una aplicacion de un punto de venta más eficiente que una hecha en FoxPro caracter.


white_spacer


danipiana@hotmail.com
05 de Octubre de 2007white_spacer
si

white_spacer


MARTIN MARROQUIN ALVAREZ
30 de Abril de 2006white_spacer
YO QUISIERA SABER SOBRE LA PROGRAMACION,LA FILOSOFIA,LA VARIBLE,RPOGRAMACION

white_spacer


Fernando
05 de Mayo de 2005white_spacer
Comentario relacionado con el tema: ¿Porque un sistema en visual Basic .NET es mucho mas complicado de desarrollar y es mucho mas lento de correr que uno desarrollado hace mas de diez años en clipper??
En algunos aspectos del desarrollo del soft creo que hemos involucionado...


white_spacer


Gerardo Quincke
06 de Octubre de 2003white_spacer
Sin hacer un análisis demasiado detallado del artículo, pienso que se tratan 2 temas independientes:
1) A qué deberían dedicar tiempo los programadores de las empresas.
2) Aspectos técnicos de la programación.

Si la respuesta a 1) es que están dedicando tiempo a mantener aplicaciones con poco valor competitivo para la empresa, seguramente en aplicativos tipo contable o RRHH, creo que la empresa debería preguntarse por qué mantener este aplicativo internamente y no comprarlo a un proveedor especializado de aplicaciones.

2) Acá no estoy de acuerdo 100% con el artículo. Por ejemplo, un mal diseño de una consulta de base de datos puede hacer que un programa ejecute 100 a 1000 veces más lento y esto no se corrije con cpu o discos más rápidos.
Sí estoy de acuerdo en usar las herramientas actuales de análisis y desarrollo, lenguajes de programación modernos, etc.
Esta programación tiene que resolver 2 aspectos: el de negocios (funcionalidad, valor agregado para sus clientes) y el técnico (rendimiento, seguridad, etc.). No creo que ninguna empresa de software pueda ser exitosa si no resuelve bien el aspecto técnico. Obviamente es un tema de escala: una cosa es tener algunos programadores para optimizar y mejorar una programación que usan decenas (o cientos o miles) del clientes y otra cosa es tenerlos solamente para la programación interna.

Por eso la programación "interna" debería remitirse solamente a lo que realmente agrega valor a la empresa.


white_spacer


white_spacer

Usabilidad Estrategia Presentaciones Otros Temas Casos Otros Autores

white_spacer

     Contactar      Comentarios sobre el sitio      Valoraciones      Privacidad      Curriculum


Late Latino

calific1

  8

calific2

  0

calific3

  1

calific4

  1

calific5

  1

calific7

  2

calific8

  7

 

Articles in English