Después de Recuperando programas antiguos: Los programas y Recuperando programas antiguos: El proceso, dejadme que de paso a algunas conclusiones, o lecciones aprendidas.

Lo primero que he percibido, es que lo que cuentan son las buenas ideas, al punto que nos motiven en su desarrollo. Pero sirve también copiar a los grandes, mejorando aquellos aspectos que no nos acaben de convencer.

En el proceso de aprendizaje, no debemos infravalorar nuestras creaciones. Da igual que fueran pruebas, experimentos, o proyectos inacabados. Con el paso del tiempo, pueden tener un valor emocional importante para ti. Admito que en los años 80 y 90, el precio de los discos, no era asequible precisamente. Muchos proyectos, no los guardábamos, por puros motivos de economía. No vale la pena, al final me encontré con disquetes vacíos que podía haber aprovechado para hacer copias de seguridad.

Un problema habitual cuando empezados, es el de subestimar el esfuerzo. Es decir, embarcarnos en proyectos, que por falta de previsión inicial, o por no percibir todos los detalles, resultan más complejos y largos de lo esperado, lo que inevitablemente ocasionará que nunca se termine. En mi caso, lo aprendí de manera temprana. Ya en tiempos del Spectrum, me propuse por varias veces crear un juego de naves espaciales. Me di cuenta que ni por conocimientos, ni por tecnología, era un proyecto viable, así que decidí centrarme en cosas más pequeñas. Lo cierto es que cuando tienes una idea en la cabeza, siempre parece relativamente sencilla. La ves clara y distinta como decís Descartes. Es cuando la desentrañas en un papel, y empiezas a desglosarla en código, que descubres que consta de múltiples detalles en los que no habías reparado. Es la ley del 80/20, que hoy día aún tiene mayor vigencia. El 80% de la funcionalidad, requiere solamente el 20% del esfuerzo. Es el 20% restante, el que necesitará de ese 80% de trabajo extra.

Por ello, no debería extrañarnos, ver muchas programas aparentemente completos, pero con detalles por pulir. El 80% del principio, es el más motivador, un avance rápido, que motiva a seguir escribiendo. Donde se resuelven de manera intuitiva la mayoría de dificultades. En cambio, el 20% del final, son las partes tediosas que, aunque fuera de manera inconsciente, hemos ido postergando. Lo que incluye depurar (debugging) de los errores; y perfilar (profilling) del rendimiento. En mi caso, ambos aspectos me gustaban, y se me daban bien, por lo que no tenía mayores problemas.

Le seguían las tareas de optimización y review, repasar el código, y ver dónde se podía estructurar mejor, o implementar mejor. Ya fuera por motivos de mantenibilidad, como de rendimiento. Iba un tanto cojo en las pruebas, era lento, y poco gratificante. En cuanto a la optimización, siempre la encontré fundamental.

Resulta extraño darse cuenta como poco a poco, uno iba ganando experiencia. En efecto, se trataba solamente de una afición, y tal vez nos pasara totalmente desapercibido. Sin embargo, es obvio que en esos 8 años de programas, el avance es patente. De simples “juegos de niños” al principio, a implementaciones que podría denominar de “calidad comercial”.





Años de trabajo duro, pero también disfrutado intensamente. Gracias a los cuales, se van puliendo errores. Un aprendizaje, por el que inevitablemente debemos pasar, y que me alegra ocurriera hace tantos años. De hecho, ojalá hubiera podido hacerlo mucho antes. Todos tendremos recuerdos de errores en el sector profesional actual, que nos recuerdan situaciones que nosotros ya vivimos, y lo que es más importante, superamos, hace casi 30 años.

El tópico del aumento de la productividad, cada nueva herramienta que sale al mercado, ya sea un lenguaje de programación, biblioteca, entorno de desarrollo o framework, nos promete mejoras increíbles. Simplemente nunca fue cierto en tal medida, aunque hay que admitir que ha mejorado. Muchas veces con detalles, hardware más capaz de compilaba más rápido, editores de código con resaltado de sintaxis o funciones de autocompletar, pantallas donde poder ver más código de golpe, y lo que parece una tontería. La mejora del Copiar y Pegar.

Para que os hagáis una idea, algunos programas en Turbo Basic, tardaban en compilar más de 30 segundos, eran desarrollos pequeños o medianos. Los proyectos más grandes en Borland C++, a veces llevaban minutos. Nada que ver con hoy en día, donde FileOptimizer se compila en menos de 10 segundos. Lo que hemos perdido, es el descubrimiento y la ingeniería inversa. Encontrabas algo que te gustaba, y te buscabas la vida para ver cómo lo hacía.

Sin apoyo, era complicado adoptar nuevas tecnologías, así que los avances eran muy lentos, pero al mismo tiempo muy seguros, pues los descubríamos por uno mismo. Imaginaros lo que era enfrentarse a Turbo Basic, del que no teníamos ni siquiera una referencia del lenguaje, ni una ayuda integrada que nos guiase ante nuevas características. Por ello, valoraba Quick BASIC, con una ayuda espectacular, que incluía ejemplos, y que sería después todavía mejor con Turbo Pascal y Turbo C.

Es curioso mirar en retrospectiva como aquellos años, acaban marcando el perfil y la evolución de uno mismo. Independientemente que las tecnologías actuales no se parezcan a las de antaño, me recuerdo dirigiendo a Rog, o compartiendo ideas con Tat, y eso es básicamente lo que ahora hago sin demasiadas diferencias. Esta vez de manera profesional.

En aquella época, no tan lejana por otro lado, los conocimientos eran un boca a oreja basado en experiencias compartidas, y lo que podíamos sacar gracias al intercambio de libros o revistas. Materiales impresos, que tampoco eran fácilmente accesibles. En las bibliotecas eran imposibles de conseguir ese tipo de recursos, y muchos estaban en inglés.

Me alegra haber mantenido la pasión por la programación, algo que se refleja también en mi faceta de aficionado. Una etapa, por la que te das cuenta que muy pocos han pasado. ¿Cuántos fragmentos de código habrá copiados de Stack Overflow sin que el desarrollador comprendiera muy bien lo que hacen?

Imagino esos tiempos en blanco y negro. Nadie entendía muy bien de qué serviría la programación en la vida. Y los que se dedicaban a ella, eran tan escasos, estaban tan alejados de mi, y a su vez eran tan opacos, que en el camino siempre me sentí un poco solo. Conseguí sobreponerme, y emprender la aventura lo mejor que pude. Hoy, no lo cambiaría.

No quiero dejar de lado, la fiabilidad conseguida por esos ancianos disquettes, que han sido capaces de mantener el contenido sano y salvo. Afortunadamente, aún existe ZIP y ARJ. Mientras que AIN puede ejecutarse sin problemas.