Lo que aprendí de la “vieja escuela”

Repasando unos viejos artículos he encontrado, por casualidad, que hace unos días ha sido el 35 aniversario del lanzamiento de Lotus 1-2-3, una de las primeras hojas de cálculo (la primera fue VisiCalc). Esta aplicación se caracterizaba por ser la más rápida del mercado, lo que posibilitó una rápida expansión, logrando dominar el mercado de forma casi instantánea, y durante muchos años.

Este tipo de aplicaciones transformaron los ordenadores personales, de ser un hobby a convertirse en una herramienta empresarial ampliamente usada en casi cualquier ámbito. Las empresas adquirían ordenadores sólo para disponer de esta poderosa herramienta. De hecho, las hojas de cálculo siguen siendo las herramientas más utilizadas en el ámbito empresarial.

Incluso el propio Windows pasó de ser uno más en el mercado (existían otros entornos gráficos muy usados en el mundo del PC, como GEM por nombrar alguno), a convertirse en el entorno gráfico líder gracias a Excel que, recordemos, apareció primero en Mac. Se ve que la estrategia de lanzar las aplicaciones primero en Apple no es nueva.

Esta aplicación, en gran medida, fue responsable de la gran expansión del mercado de la informática, siendo necesarias cada vez más aplicaciones de tipo específico para la resolución de problemas. Gran parte de nuestro trabajo se lo debemos a estas primeras herramientas.

Lotus 1-2-3 era extremadamente rápida en sus cálculos, y en la representación de los datos en pantalla. Podía manejar grandes cuadrículas de datos a gran velocidad, gracias a un trabajo muy bien hecho, y no precisamente fácil. Estaba desarrollado en lenguaje ensamblador de x86, por lo que, en lugar de utilizar las funciones previstas en el sistema operativo, hacía uso directamente de los recursos de la máquina, de forma muy eficiente.

En aquellos tiempos nuestro trabajo era muy diferente. No diré que fuera mejor o peor que ahora. Simplemente diferente. Muchos se acordarán de cuando se compilaba una aplicación. Había que pensarlo muchas veces antes de hacerlo, ya que el proceso podía durar horas. Los editores no disponían de tecnologías como Intellisense y, si habíamos cometido algún error de sintaxis, era necesario corregirlo y volver a empezar… y varias horas más de compilación.

No hablemos ya de errores más serios, que no dan errores en la compilación. Quizás los desarrolladores estaban más atentos a estos fallos. Yo no he conocido los complejos desarrollos de sistemas mainframe, pero si otros compiladores más… digamos modestos. El proceso de compilar y, posteriormente, si todo iba bien, enlazar la aplicación, podía ser muy tedioso.

Por ello, antes de iniciar no sólo un proyecto grande, sino cualquier pequeña rutina que se desarrollaba, era más frecuente sentarse a planificar. Cuando estudiaba, era muy común que los profesores nos advirtieran del peligro de dejarnos seducir por el impulso de ponernos a codificar inmediatamente. A todos nos ha pasado, y que arroje la primera piedra aquel que no haya tenido que rehacer completamente el código después de darse cuenta de que no era exactamente lo que pretendía. Parafraseando a cierto personaje (todos sabemos quién) de cierta película, “es un defecto muy extendido, no sólo entre los jed… perdón, desarrolladores más jóvenes, sino entre los viejos, con más experiencia”.

Hoy disponemos de multitud de herramientas que nos ayudan en nuestro trabajo diario, y que nos facilitan esta labor enormemente, pero sigue siendo imprescindible planificar el trabajo, aunque no dispongamos de tiempo. Recordad siempre, que “varias horas de codificación pueden ahorrarnos unos minutos de planificación”. Es buena costumbre sentarse a primera hora, todo el equipo, con un café en la mano, para hablar del estado del desarrollo, y de lo que se va a hacer en la jornada que empieza. No en vano es uno de los pilares de las metodologías ágiles.

Otro fallo importante ha sido, tradicionalmente, medir el desarrollo en líneas de código. Este último, afortunadamente, cada vez menos extendido. Recuerdo haber leído alguna vez que la primera versión de OS/2, el sistema operativo de IBM para los 90 (y, perdonadme que lo diga, muy superior a Windows en prácticamente todo), fue un desarrollo conjunto de IBM y Microsoft. De hecho, buscad capturas de pantalla de la versión 1.3 de OS/2 y de Windows 2.0. ¿No os suena?

El caso con aquel desarrollo es que fue un fracaso tanto comercial como técnico. De la parte técnica se puede decir algo revelador: Microsoft cobraba por cada línea de código. Os podéis imaginar las consecuencias: un algoritmo que se desarrolla con 1000 líneas de código se puede optimizar, dejándolo en 100, invirtiendo “tan sólo” unas cuantas horas. Bueno, pues como cobramos por líneas de código, nos ahorramos esas horas y ganamos más. Y ese módulo, que no está optimizado, si resultara ser parte del núcleo, se convertirá en un lastre para todo el sistema. A IBM no le quedó otra que desarrollar ellos el sistema (la versión 2) desde casi cero, esta vez optimizando todo lo posible. El resultado fue bueno, pero OS/2 no se recuperó jamás, y Windows 95 se impuso a OS/2 3.0 por mucha diferencia. Hubo otras razones, más comerciales, pero eso es otra historia. Sin duda merece la pena invertir ese tiempo extra no en hacer que nuestra aplicación funcione, sino que funcione mejor y, una vez que lo hayamos conseguido, intentar mejorarla de nuevo. Nuestro cliente lo agradecerá.

Existen multitud de ejemplos más, en un sentido o en otro, de los que siempre podremos aprender y sacar nuestras propias conclusiones, pero creo que nunca debemos olvidar las lecciones aprendidas de aquellos viejos desarrollos. Debemos utilizar, en la medida de lo posible, la experiencia de otros profesionales para mejorar en nuestro trabajo.

Al fin y al cabo, ha sido ese recorrido por la historia de la programación el que nos ha traído a este momento, con todas estas tecnologías y avances en nuestro campo. Y lo mejor aún está por llegar. Recordad que nuestra primera obligación como desarrolladores es seguir aprendiendo.

Autor | José Manuel Morillas Navarro, Analista Programador – Soluciones Microsoft Sogeti Spain