¿Has oído alguna vez decir que los ordenadores que se utilizaron para llevar a la gente a la luna son mucho menos potentes que los que hay en tu smartphone? Es cierto. De hecho, son menos potentes que lo que hay en tu lavadora, suponiendo que la hayas comprado en los últimos años. Todos hemos visto cómo la tecnología ha aumentado en capacidad y complejidad tanto como ha disminuido en tamaño físico. El código de la computadora de guiado del Apolo 11 se ha publicado recientemente en GitHub para que podamos maravillarnos de la ingeniería que se empleó en ese estupendo proyecto. Pero, si echas un vistazo a ese código, no es nada fácil de leer. Cuando tienes 64k de memoria con los que jugar (una cantidad tan inconcebiblemente pequeña para la mayoría de la gente ahora que ni siquiera vale la pena intentar describirla) tu código debe ser «cercano a la máquina». Esto significa que no necesita mucha traducción para convertirlo en un verdadero lenguaje informático.
Con el paso del tiempo, los ordenadores se hicieron más potentes, más capaces de esa traducción, y se diseñaron más lenguajes de programación legibles para el ser humano. A principios de la década de 1980, a alguien se le ocurrió la idea de los lenguajes de cuarta generación (4GL). Este concepto es un lenguaje informático que está tan alejado de «la máquina» como para ser altamente comprensible por los humanos. Las herramientas suelen generar un código secundario en un lenguaje de programación más común (como C++) que, a su vez, se traduce al lenguaje propio de la máquina. De este modo, según la idea, podemos desarrollar software más rápido y de mayor calidad, sin necesidad de contar con todos esos complicados conocimientos que requerían los primeros programadores.
La oportunidad
Hoy en día, esas 4GL han reaparecido como herramientas de «bajo código» y «sin código», como OutSystems, Mendix y Microsoft PowerApps, por mencionar algunas de las muchas herramientas disponibles. En los últimos años han cobrado más fuerza, lo que ha dado lugar al surgimiento de lo que se denomina «desarrollador ciudadano». Se trata de un empleado que crea aplicaciones para su uso o el de otros, pero cuyo trabajo no es el de desarrollador a tiempo completo en el equipo de TI. En IDC hemos pronosticado que el número de desarrolladores de bajo o ningún código aumentará significativamente en los próximos años, y una buena proporción de ellos serán «desarrolladores ciudadanos».
Para algunos, esto es alentador. En muchas organizaciones existe un auténtico déficit de competencias. Contratar a desarrolladores a tiempo completo es caro, si es que se puede encontrar, y perdemos mucho «know-how» si nos dejan, independientemente de lo bien que gestionemos nuestras bases de conocimiento y el código fuente. Además, el software se desarrolla a menudo sobre la base de unos requisitos mal interpretados, lo que lleva a una costosa reelaboración para alinearlo con los requisitos reales, incluso en un mundo ágil. Por eso, conseguir que los usuarios finales reales participen en la producción real del software puede ser una ventaja definitiva en muchos sentidos.
No es todo un camino de rosas
Sin embargo, para otros hay muchas preocupaciones. El desarrollo de software es una disciplina que ha crecido a lo largo de décadas y, aparte de las habilidades técnicas necesarias, hay un montón de costumbres y prácticas de gobierno importantes que los desarrolladores «a tiempo parcial» pueden no entender o aplicar. Aspectos como las pruebas estructuradas, el control de versiones, la seguridad y una estrategia de soporte a largo plazo deberían formar parte de todo programa de desarrollo, independientemente de las herramientas que se utilicen para crear el software.
El uso y abuso de los datos también es una consideración clave. Hay que asegurarse de que los datos que utilizan estas nuevas aplicaciones están actualizados, son relevantes y no suponen un riesgo potencial para la seguridad o la privacidad si se exponen a través de una de estas herramientas. Otro factor a tener en cuenta es que las aplicaciones que consumen datos de la empresa pero están mal escritas pueden inducir a error al usuario y potencialmente hacer que se tomen decisiones basadas en información errónea con un coste significativo. También hay que gestionar otras cuestiones, como la accesibilidad, el cumplimiento de las políticas de la empresa y la normativa. Se puede entender por qué algunos ven con horror la idea de un ejército de desarrolladores «amateurs».
Para conseguir las numerosas ventajas de las herramientas de bajo o nulo código y, al mismo tiempo, mitigar estos riesgos, hay que abordar las cuestiones de gobernanza, y el equipo que debe ocuparse de ello es, por supuesto, el de TI. La gobernanza, que incluye herramientas, recursos y apoyo a estas actividades, convierte a los desarrolladores a tiempo parcial en auténticos «desarrolladores ciudadanos». Si el director de informática no proporciona este apoyo, según mi experiencia, los desarrolladores a tiempo parcial harán su trabajo de todos modos, y el equipo de informática acabará limpiando el desorden.
Conclusión
Antes de embarcarse en cualquier implementación de herramientas de bajo o ningún código en su empresa, asegúrese de haber marcado estas casillas a través del equipo de TI y de haber comprendido los requisitos de soporte en el futuro.
- Seguridad
- Soporte de la aplicación
- Formación
- Valoración y gestión de los datos
