Recuperando programas antiguos: Conclusiones

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


Recuperando programas antiguos: Conclusiones
Recuperando programas antiguos: Conclusiones

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.


Recuperando programas antiguos: Conclusiones

4 comentarios en “Recuperando programas antiguos: Conclusiones”

  1. Mucha razón tienes con lo del 80-20 (ya hablo como Yoda y todo… :D), y lo peor es cuando acabas reconociendo que, por muchos esfuerzo que inviertas, siempre habrá cosas que se te escapen o cosas que tal vez ni el lenguaje te permita realizar. Me he encontrado así en alguna ocasión, preguntándome: “bueno, puedo crear una librería o una función especial para ello”, y resulta que si lo hacía, al final iba a ser más complejo hacer eso que hacer la aplicación entera 😛 Así que lo dejaba y asumía que, además de poca paciencia, tengo poca perseverancia. Admiro tu capacidad de estar semanas y semanas en un proyecto, yo si pasaba de los dos días ya me aburría, por eso me gustaban -y me gustan- las aplicaciones “aquí te pillo aquí te mato”, aunque es cierto que luego actualizaba y las mejoraba a través de versiones, pero eso me costaba menos trabajo… No se por qué.

    Yo, como a ti, me preocupa también mucho la optimización. De hecho creo que debería ser fundamental desde el principio, en el desarrollo de cualquier aplicación. No entiendo ni concibo otra cosa. Si no es así, optimizarla luego es mucho más complicado, aunque es verdad que a veces lo he hecho. Pero tanto como es un proceso constante la optimización, también lo es su implementación, que debería ser desde los primeros estadios de la aplicación.

    Yo también estuve mucho tiempo programando solo, por eso me inventaba bots que me acompañaran y me animaran 😀 Ahora veo un cajero automático de estos de última generación, y vamos, es como de la familia. En cuanto los automóviles autónomos se hagan comunes, serán como mis primos hermanos. Aunque por elegir, me decantaría por “cositas” como ésta:
    http://revistacoche.blogspot.com/2017/02/case-presenta-el-tractor-que-se-conduce.html

  2. Javier Gutiérrez Chamorro (Guti)

    Bueno, me ocurre como a ti. Los primeros 3 o 4 días, son los más motivantes. Te pasas todo el tiempo posible escribiendo código, duermes poco, pero los avances son muy grandes. Te sientes realizado, y parece que tengas una productivdad en plan super-heroe. Luego viene la parte más tediosa, de machaca de ir mejorando, puliendo detalles, optimizando, probando, … Y hasta que consigues una versión usable y estable, esa es la peor parte. Como bien dices, luego se repite la parte divertida, vuelves a añadir funcionalidades que se te han ocurrido o sugerido, y pasas algunos días más disfrutando a tope. Después, de nuevo probar, y pulir los detalles y lo que se ha roto…

    Coincido contigo en la optimización. Si no la aplicas desde el principio, tanto en cuanto a código, como en cuanto a algoritmos, luego la optimización, son solamente parches, que causan que el código sea difícil de leer, y las mejoras obtenidas sean muy pequeñas. Cuando digo optimización de algoritmos, me refiero a que es mejor que implementes un quick-sort sin esforzarte mucho, que el de ordenación de la baraja, por más optimizado que esté el código. A veces, perdemos ese contexto, y nos dedicamos a refactorizar y reescribir un código, que aunque es buenísimo, apoya un algoritmo bastante malo.

    Lo que más admiro de los años 80 en cuanto a informática, era la época de los 8 bits, donde una mente brillante, era capaz de crear un juegazo al completo en 3 meses, incluyendo gráficos, música, rutinas, lógica de juego, y a veces, hasta el manual con su historia. Ahora eso resulta imposible, salvo que hablemos de miniproyectos tipo aficionado, que tan bien tu y yo conocemos. Aunque luego lo piensas, y te das cuenta de virguerías como el sistema de archivos ext4, que las desarrolló sólo una persona sobre ext3 en menos de 1 mes, y que ahora mueve la mayoría de distribuciones de Linux. En cambio Microsoft, parece que es incapaz de saber como se escribió NTFS. Las malas lenguas, dicen incluso que perdieron el código fuente de esa parte.

  3. Pues sí, me suenan algunas cosas (sólo algunas) de las que mencionáis. Lo de programar en solitario ha sido siempre mi sino, dada mi aproximación a este mundo como mero aficionado sin mayor pretensión que saltar retos personales.
    Por eso, optimizar el código de un algoritmo decente y funcional no me ha quitado muchas veces el sueño. Eso para losprofesionales jejeje.
    En cualquier caso, creo que afrontar la programación como el reto de enseñar a una máquina que nada sabe hacer sin recibir órdenes precisas y estrictas asta lo exasperante, ayuda a clarificar y estructurar el pensamiento propio. Una especie de retroalimentación mental (me dan ganas de borrarlo :-)) jejeje
    Saludos.

  4. Javier Gutiérrez Chamorro (Guti)

    ¡Exacto Ngr! Siempre he pensado lo mismo. Eso de hacer que una máquina “tonta” te entienda y haga lo que tu quieres lo encuentro extremadamente motivante. Por mi parte lo de optimizar, si me gusta/gustaba. Se trata de exigirte más a ti mismo, y hacer las cosas mejor. Más con menos.

Deja un comentario