Batallitas de un ingeniero informático del siglo XX
Llevo más de 40 años en el negocio de la ingeniería informática y nunca fui tan feliz como cuando programaba, es decir, escribía código. Creo que esta frase es compartida por muchos de los que nos dedicamos a esto y hemos tenido la fortuna de ir escalando en los diferentes roles de este sector.
Empecé en 1986, cuando ya atrás quedaban aquellos héroes de las tarjetas perforadas y las cintas. Eran tiempos en que todavía escribíamos el código en un papel, pero ya no vestíamos bata blanca.
Era una época en que el error era un error y te lo recordaban a la mínima ocasión. No era un “bug” concebido como parte del proceso de maduración, como si los programas se tuvieran que acabar de hacerse al sol.
Actualmente nuestro sector es excesivamente tolerante con el error y esto ha ido empeorando a medida que han ido avanzando los lenguajes de programación y sus entornos.
El “copy/paste”, el “debug”, el “autocompleto” o el “intellisense” y las IA han ido conduciendo a una sistemática en la que se construye asumiendo el error, pensando poco, haciendo desarrollo a base de ensayo y error, abandonando la algorítmica propia y confiando a ciegas en la reutilización.
Para mí, uno de los estímulos de programar era conseguir cero errores en el primer intento, como un “hole in one”. Era ciertamente un mito, pero perseguir este mito me permitía disfrutar de la concentración que suponía la programación. Todo a mi alrededor desaparecía durante horas, días e, incluso, noches. Si cuando hacía el “run” el resultado no era el esperado, ya era un error porque tendría que haber funcionado a la primera.
El otro placer relacionado con la programación era diagnosticar. Antiguamente, había que actuar un poco como el Dr. House. Como a partir de ciertos hechos y proposiciones podíamos ser capaces de diagnosticar la causa de una incidencia y corregirla. Quiero recordar que no existía la opción de “debug”, ni el control remoto. Lo digo para los más jóvenes programadores, en aquella época poníamos “chivatos” en el código para comprobar contenidos en las variables, que, además, tenías que ahorrar para no ocupar demasiada memoria.
Reconocer un error era una vergüenza porque quedabas muy señalado. Además, no te podías esconder.
Rehacer una versión y hacerla llegar a tus clientes era todo menos inmediato. Lejos estaba eso de hacer un “push” en la rama master. El impacto para remontar un paquete de instalación y hacerlo llegar a los clientes era un trayecto que podía durar una semana.
Y es que estamos hablando de la época antes de Internet. Es necesario que sabéis, programadores novatos, que había informáticos antes de internet y no había “github”, ni código abierto, ni IA, ni correo electrónico.
Estos jóvenes programadores se preguntarán cómo nos lo hacíamos en el siglo XX para hacer las entregas a cliente. Pues debéis saber que preparábamos una imagen máster para grabar en unos disquetes. Montábamos másteres de hasta 5 disquetes de 5 1/4″ o de 3 1/2″. Los de bata blanca habían utilizado los de 8″ que yo ya ni los viví. Con el tiempo nos proveíamos de una máquina duplicadora que nos permitía automatizar las copias. Eso ya era un lujo porque antes se hacía a mano. Preparábamos la hoja de instalación con sobres y etiquetas para cada cliente. En nuestro caso, podíamos tener unos 1000 clientes según la aplicación.
Se avisaba a correos y se hacía la entrega de los sobres que teníamos que enviar. No había otros medios y correos funcionaba muy bien.
Según si la habías “liado muy parda”, pagabas servicio urgente que podía tardar 2 días en llegar en todo el Estado.
Ahora, programador novato, imaginate hacer tú la “cagada” porque no has probado lo suficientemente bien un algoritmo, cuando ya se han replicado 3.000 disquetes: Sólo para hacer las copias te has pasado 2 días, has pagado (en pesetas) todos los envíos y que, para el colmo de los colmos, quien te lo detecta es un cliente de las Islas Canarias.
Cada “bug” y su “hotfix” lo tenías grabado en la memoria de todos la primera vez que eras el causante y si la volvías a “cagar” pasabas a mejor vida.
¡Soy de la generación que superó el efecto 2000! No hace falta decir nada más… Todo tenía que funcionar a la primera cuando cambió el siglo. No podías esperar al siguiente cambio de siglo para hacerlo mejor.
Ahora, me explicaba un ingeniero, cómo es la vida del programador hoy: tiene que implementar una API a partir de un PDF que le han hecho llegar; Le da pereza teclearlo y lo pasa a la IA para que le parsee el documento y le cree un DTO. Como hay otra clase muy similar documentada, pero no tiene claro si es igual, le pide a la IA que le diga las diferencias y encuentra que le faltaban dos campos (que seguramente quien documentó la API se los había dejado). Como el PDF corta la clase en dos páginas, le pide a la IA que añada los campos de la segunda página al DTO inicial y que le implemente una serie de inicializaciones y conversiones.
Con tanta IA de por medio, un trabajo hecho en una hora, ahora se puede hacer en 5 minutos. Pero ahora hay que valorar si esta aceleración de la productividad no es inversamente proporcional a la robustez.
Antes, había múltiples sistemas operativos: OASIS, THEOS, MS-DOS, XENIX, UNIX ATT, UNIX SCO, AIX… Algunos fabricantes de aplicaciones creábamos lenguajes interpretados con “runtimas” por plataforma y así minimizar el coste de programación y de pruebas. Por eso se inventaron los “frameworks”: nivelar a todos los programadores para que todo se hiciera de la misma manera y todo el mundo pudiera mantener el código. No es muy diferente a lo que pasa ahora con las App, las Webapp y los frameworks para disponer soluciones crossplatform, pero quizás también ya ha quedado desfasado mientras estoy redactando estas reflexiones.
No sé si este joven programador de hoy disfruta tanto como disfruté yo.
Nosotros desarrollamos compiladores, “runtimas” multisistema operativo o generadores de código. Creamos lenguajes de 4G y fuimos los inventores de los frameworks. Empezamos a pasar de la codificación en papel al diseño UML y diagramas estáticos de clases. Inventamos los patrones de diseño y vivimos las transiciones entre aplicaciones de servidor, aplicaciones desktop, aplicaciones cliente-servidor y de nuevo hacia el cloud y de nuevo hacia el móvil.
De alguna manera que todavía desconozco, enseñamos a las IA a dejaros sin trabajo en breve.
Recent Comments