IT, we have a problem / Por Gabriel Catelli

0
643

Aunque la frase real fue “Okay, Houston, we’ve had a problem here”, la que se hizo famosa fue la que titula este artículo.

La crisis del software no es nueva. De hecho, fue acuñada en 1968 durante una conferencia de la OTAN en 1968 (https://www.scrummanager.net/files/nato1968e.pdf). La razón principal que se esgrimía en esa época es que las computadoras se habían convertido en dispositivos muy poderosos.

Desde esa fecha y con altibajos, nunca salimos de esa crisis, la industria de la tecnología vive en esa crisis continua, donde el software necesario nunca es producido en la cantidad y calidad necesaria. No significa esto que no haya software de calidad, se necesita mucho más, más programadores y más rápidos.

Pero si en 1968, considerábamos que estábamos en crisis debido a esas computadoras tan poderosas, ¿en qué situación estamos ahora cuando la capacidad de procesamiento se ha multiplicado por 50.000.000 de veces? Decir peor es optimista.

De acuerdo con el US Labour Statistics, en 2020 existía a nivel global una falta de talento del orden de los 40 millones de expertos y que para 2030 esa cifra crecerá hasta los 85.2 millones. Esto causa pérdidas a nivel global del orden de 8.4 trillones de dólares.

Es imposible que cubramos ese déficit de aquí a 2030 y si continuamos con los métodos tradicionales, esa cifra solamente se hará mayor. La transformación en la que la humanidad está inmersa, desde varios puntos de vista, tiene como eje fundamental, la tecnología la cual principalmente tiene 2 grandes vertientes: hardware y software. La primera no para de crecer y la segunda de tener más problemas.

Como es imposible cubrir esa demanda con los métodos tradicionales, es decir generar más programadores, la opción a corto mediano plazo es que los mismos sean más eficientes, e incluso lograr que gente no especializada, puede por lo menos, cumplir roles que requieran conocimientos técnicos menores.

Finalmente se trata de reducir los tiempos, generar software mas eficiente que cumpla con los requerimientos del usuario y que se evite el retrabajo usual.

Evolucionamos de Asembler, FORTRAN, COBOL, C, C++. C#, Java, Python, etc., haciendo una lista resumida del recorrido, pero es una lista interminable. Sin duda se ha evolucionado mucho y actualmente es menos artesanal y es más colaborativo, con mucho open source de alta calidad.

Recuerdo en mis tiempos de programador, fines de los 80, principios de los 90, en Uruguay surgió Genexus, una herramienta que se podría decir de low code (no es exactamente, pero digamos que fue un intento de hacer más efectiva la tarea del programador).

En 2014 se empieza a hablar del low code y permítanme dejar este extracto en inglés:

El objetivo final es simplificar la tarea. Teóricamente poner al alcance de cualquier usuario la capacidad de crear algún tipo de software. El Low Code (LC) requiere más conocimientos técnicos que él No Code (NC).

La realidad es que todo seguirá evolucionando, si tendremos herramientas LC y NC mucho más eficientes y que permitirán que personas sin los conocimientos que hoy se requieren para lograr un software de calidad, puedan generarlo. Hoy tenemos herramientas como Bubble, Zoho Creator, Quickbase, Airtable, entre otros que ya permiten hacer mucho y no pararán de evolucionar y de aparecer más y mejores.

Pero por el momento, en ambos casos, salvo para casos muy simples donde no se requiere diseño de base de datos y con un drag & drop, solucionamos, si se requiere para lograr un producto de calidad, que sea un programador el que haga el desarrollo.

El desarrollo tradicional no desaparecerá en el corto mediano plazo, pero si es un hecho que cada vez tendremos más LC y NC, que además puede cumplir objetivos intermedios de generar prototipos en forma rápida que sean validados por los usuarios finales, sin necesitad de un desarrollo completo y tener algo más alineado con una metodología Agile (tenemos una metodología que promueve un manejo ágil del proyecto, pero en general las herramientas de desarrollo son las tradicionales).

Muchas áreas de tecnología tienen el temor de perder “poder” si “cualquiera” toma en sus manos el desarrollo. Siempre tememos a lo que no conocemos. Las áreas de tecnología están más seguras que nunca, siempre y cuando evolucionen y adopten las nuevas tendencias que si o si vendrán tal como llego el home office.

Finalmente, Houston solucionó el problema del Apollo 13, utilizando métodos no tradicionales.

LEAVE A REPLY

Please enter your comment!
Please enter your name here