La falta de información confiable, exacta, actual y relevante, es algo que preocupa a diario a los ejecutivos de todas las empresas, organizaciones de todo tipo e individuos, como científicos e investigadores.

Sin embargo, una multitud de factores hacen que pensar en la "administración correcta y eficiente" de la información, y pensar en esta información como un bien que tiene un determinado valor (en dinero) dentro de la compañía sea difícil sino imposible en muchas ocasiones.

En lo que se refiere a Sistemas, o IT (que es mas "cool") entre los factores que impiden pensar realmente en la administración de la información, en mi opinión los más notorios son:

• El deslumbramiento con las nuevas tecnologías: una cantidad considerable de supuestas herramientas que prometen de forma casi milagrosa darle a los puestos claves de la empresa información que ni siquiera existe en los sistemas de la compañía.
• El deslumbramiento con las nuevas herramientas de programación (en particular por los programadores del staff) que están más preocupados por utilizar determinadas características del nuevo lenguaje estrella que por hacer algo realmente útil con ese lenguaje.
• El deslumbramiento por la aplicación de nuevas metodologías de diseño, ágiles, scrum, etc... y patrones de diseño y diagramas UML y una cantidad enorme de nuevas teorías que aparecen día a día.
• El deslumbramiento (inútil para mi) con la ya bastardeada hasta el hartazgo Web 2.0
• Las ambiciones personales y negociados de muchos gerentes de sistemas.

Si a esto le sumamos las interferencias en la toma de decisiones de los comerciales, marketing y otros departamentos, terminamos con un hardware sumamente potente, herramientas de última generación y programadores que cobran una fortuna por hora y consultores de cada uno de los productos comprados para que finalmente llegue a las manos de la persona equivocada un reporte con unos gráficos espectaculares de información irrelevante, vieja, inexacta y por lo tanto totalmente inservible.

¿Cómo me parece a mi que se soluciona esto?

Diganme dinosaurio si les parece (o sean mas duros si gustan) pero la solución está en volver a las bases. En volver al simple y viejo principio de que dato + proceso = información. No importa con que herramienta o con que lenguaje se trabaje, si no hay un diseño sólido y bien pensado desde el principio y un conocimientos profundo de los datos y la información que maneja la compañía, la organización o el individuo nada de lo que se haga va a servir.

A lo largo de mi carrera he visto (y he programado yo mismo) sistemas en clipper, dBase y RPG/400 que le daban la información justa, indispensable, confiable y en tiempo y forma a quienes la necesitaban de forma urgente para tomar decisiones criticas que significaban unos cuanto miles de dolares (y sus puestos de trabajo a veces) y no usabamos cubos ni patrones de diseño ni lenguajes de última generación ni metodologías ágiles.

Lo que había era horas de relevamiento a fondo hasta conocer el mas mínimo detalle de los datos que se manejaban, la información exacta que se requería y horas de diseño de los procesos necesarios para transformar esos datos en esa información.

Con esto no digo que los cubos, los patrones de diseño, los lenguajes de última generación y las metodologías ágiles no sirven. Todo lo contrario, son indispensables hoy en día, pero inútiles si nos olvidamos de cosas tan simples como que debemos conocer "el terreno" en el que nos movemos a la perfección hasta el más mínimo detalle. Y por supuesto jamás olvidar que dato + proceso = información.

Es prácticamente imposible enseñarle a programar bien a cualquiera que haya sido expuesto anteriormente al BASIC: como potenciales programadores están mentalmente mutilados y no tienen ninguna esperanza de regeneración.

Edsger W. Dijkstra, 18 de Junio de 1975

Más allá de que Dijkstra es considerado uno de los más grandes científicos dedicados a las ciencias de la computación, ganador del premio A. M. Turing en 1972 y blah, blah, blah, no puedo dejar de considerar lo que dijo una de las más grandes estupideces de la historia de la programación.

Yo programé, en estricto orden cronológico, en:

• Sinclair BASIC
• CBM BASIC
• 6510 Assembler
• Pascal (en la C64)
• Quick Basic 4.5 (en la primer PC que tuve)
• Turbo Pascal
• Clipper
• Dbase II
• COBOL 400
• RPG/400 (RPG III)
• RPG IV
• CL/400
• Delphi 3.0
• Visual Basic 3.0
• Visual Basic 6.0
• Visual Basic Script
• VBA
• Visual Basic .NET 2005
• C# 2.0

La experiencia que me ha dejado el haber programado en todos estos lenguajes es muy sencilla. Uno no aprende o sabe programar en un lenguaje determinado, sino que uno debe aprender a programar, entendiendo el término programar como el encontrar un algoritmo que solucione un determinado problema. Este algoritmo puede expresarse primero utilizando diversas metodologías (top-down, estructurada, orientada a objetos) y luego programada en cualquiera de los lenguajes existentes.

La solución es independiente del lenguaje de programación a utilizar. Se puede ser un experto en Perl y conocer de memoria la sintaxis de todas las instrucciones pero si no se sabe pensar en la solución de un problema en términos de algoritmos y estructuras de datos, ese conocimiento del lenguaje resulta inútil.

Un mal programador lo es en cualquier lenguaje, lo mismo que un buen programador es bueno en cualquier lenguaje. Por supuesto que, una vez que tenemos la solución a nuestro problema, el sentido común dicta programarla en el lenguaje que mejor conocemos y si conocemos varios, en el que mejor se adapta a la solución encontrada.

Cualquiera que diga que una solución a un problema expresada utilizando un diseño orientado a objetos no puede programarse en el BASIC de Sinclair que usaba la ZX-Spectrum no tiene idea de lo que significa orientación a objetos y mucho menos de lo que significa programar. ¿Es esa versión de BASIC la mejor para implementar una solución orientada a objetos?. No, de ninguna manera. Es una tarea engorrosa y complicada, pero no imposible. Por supuesto que es mejor utilizar un lenguaje como VB.NET, C# o Smalltalk. Estos lenguajes fueron diseñados específicamente pensando en facilitar la implementación de soluciones orientadas a objetos.

Por eso lo que dice Dijkstra, con todo respeto lo digo, es una gilada monumental. No importa el lenguaje, sino los conceptos de programación que uno maneja. Un buen escritor en castellano, si aprende suficientemente bien otro idioma, seguirá siendo un buen escritor. El que maneja de forma excelente un Porsche, maneja de la misma forma un Fiat 600. Y así puedo seguir eternamente.

Mi primer libro de programación (que aún ojeo de vez en cuando) lo compré inmediatamente después que tuve mi primer computadora, una Timex Sinclair 2068 (un clon yanqui de la ZX-Spectrum inglesa). El libro se llama "Programación Avanzada en BASIC" de Peter Bishop. Tranquilamente se podría haber llamado simplemente "Programación Avanzada". El autor usa el BASIC simplemente como un lenguaje de referencia para demostrar prácticamente los conceptos de programación avanzada que explica en el libro. Y usa BASIC porque en aquel momento era el lenguaje que venia en la ROM de todas las computadoras hogareñas (home computers). Es más, usaba un BASIC lo más estandard posible para que los ejemplos fueran compatibles con todas las versiones de BASIC de la época. Y la mayor parte de los conceptos explicados en ese libro siguen teniendo vigencia.

Por eso cuando estoy frente a un problema (y tengo el tiempo suficiente) trato de no pensar, por lo menos al principio, en qué lenguaje específicamente voy a implementar la solución. Cuando logro hacerlo bien, la solución al problema termina siendo un algoritmo que fácilmente se puede implementar casi en cualquier lenguaje y permite además explotar las características especiales del lenguaje elegido.

Por eso Mr. D. lo suyo fue y será una tremenda patinada.