Olviden ya el Excel, por favor

Leí mi Proyecto Fin de Carrera en 1990. Entonces no lo sabía, pero iba de Machine Learning (si, has leído bien, he dicho “en 1990”). Hasta una red neuronal implementé, mira por dónde.

Me explico: se trataba de analizar muchos programas escritos en Modula-2 (antigualla…), extraerles una serie de métricas, modelar en función de ellas su calidad y también detectar posibles plagios (aquí entró la red neuronal, junto a otro tipo de modelos de clasificación basados en histogramas). No he sabido hasta hace relativamente poco que fui un adelantado del Machine Learning (qué poco he explotado yo esto…), pero sí me hizo tener desde entonces una cierta sensibilidad hacia la calidad del software y las metodologías de desarrollo.

Y ahora el desarrollo software se está generalizando en el mundo de la Analítica de Datos, la Ciencia de Datos o como queráis llamar a este mundo. Donde imperaban plataformas específicas y las sempiternas hojas Excel, ahora todo el mundo trata de hacer su trabajo con Python, R o similares. Pero hay un problema: muchos no somos informáticos, sino más bien solo unos advenedizos en el desarrollo software. Y ¿qué hacemos? Intentamos usar R o Python como usábamos el Excel. Es como si, después de muchos años juntando tablas usando clavos y un martillo, ahora nos los hubieran cambiado por tornillos y un destornillador. Claro, pasa lo que pasa: nos dedicamos a aporrear los tornillos con él. La cosa no solo no mejora, sino que puede empeorar notoriamente.

Por ejemplo, qué maravilla, podemos hacer más código y muy deprisa acudiendo al viejo truco del Excel: ¡el copy-paste! “¿Qué? ¿Qué hay una cosa que se llama ‘modularizar’, incluso otra que dicen ‘función’? ¡Bah! Si voy mucho más deprisa así…”

O también: “pues yo antes hacía los gráficos mucho más deprisa en Excel…” Si, claro, pero una vez que programas uno, puedes reutilizarlo ¿no? “Ya, pero tardo mucho y no llego a la próxima entrega…” Nos encanta reinventar la rueda… porque “tardamos menos”, jajaja.

Así, trasladamos al desarrollo del software otro de los problemas del Excel: (3 meses después) “¿Cómo demonios hice yo esto?”. O, peor: “¿cómo $%#!! hizo esto fulanito? Mejor lo tiro y lo hago de cero”. Si, lo bueno del Excel es que no documentábamos. Ah, pero lo bueno del software es que podemos seguir sin documentar. No sea que no lleguemos a la próxima entrega…

Otra maravilla del Excel: no hay que hacer pruebas para saber si está bien hecho o no. Claro, luego pasan cosas como que el MI5 pinche los teléfonos equivocados, dos prestigiosos economistas aconsejen la política equivocada a la UE o el Reino Unido “traspapele” 16 000 casos de enfermos de COVID19. Claro que, si no lo hacíamos en Excel, también podemos no hacerlo en R y tan contentos, ¿no?

Y así, seguimos liberando software “a piñón”, sin nada que se parezca a un diseño previo, más bien por mera evolución a petición popular, sin pruebas, sin revisión por otros, sin modularidad, sin documentación. Pero corremos mucho, eso sí. Llegaremos a tiempo.

Ya no es solo el problema clásico de si este software hace lo que tiene que hacer (y no otra cosa) y además lo hace eficientemente: es que perdemos las ventajas de automatizar (que es sinónimo de capitalizar nuestro negocio y/o añadir valor al cliente) y encima, no adquirimos la capacidad de replicar y reproducir los resultados.

Entiéndanme: no digo que haya que dejar las hojas de cálculo, hacen bien su trabajo: si tienen que clavar un clavo, usen un martillo. Pero para atornillar cosas, cambien de herramientas, sí, pero, sobre todo: ¡cambien de metodología!