NoCode y Desarrollo de Software: Enemigos íntimos

El movimiento NoCode está pegando fuerte últimamente. Existe una comunidad cada vez más madura de profesionales que se zambullen en estas herramientas para solucionar casos de uso de negocio sin recurrir a Desarrollo de Software tradicional. Entre los casos de uso que se suelen poner como ejemplo están la construcción de prototipos y MVPs, la integración de datos entre diferentes herramientas, la automatización de tareas o la gestión de bases de datos de manera sencilla. Todo esto ha pertenecido tradicionalmente al dominio del desarrollo, al Code puro y duro. ¿Le está entonces comiendo terreno el NoCode al Software tradicional? ¿Tengo que posicionarme en un bando? ¿Hay tomate?

Pensar que existe una frontera infranqueable entre el Desarrollo de Software y NoCode es, a nuestro modo de ver, algo naive. Es cierto que es posible construir un sistema de cierta complejidad combinando la potencia de varias herramientas sin programar una única línea de código, y hay multitud de ejemplos que lo atestiguan. También habría quien podría argumentar que todo lo que uno puede construir empalmando herramientas NoCode lo puede hacer también desarrollando software tradicional, y que esto daría lugar a soluciones más optimizadas y menos dependientes de herramientas de terceros. Sin embargo, los sistemas de información evolucionan, y esta evolución nos lleva a un escenario de fusión de ambos mundos.

Conexión

El movimiento NoCode es fundamentalmente integrador. Es difícil encontrar una solución que no implique el uso de varias herramientas. Podríamos decir que, de hecho, la integración forma parte de su naturaleza. Todas las herramientas NoCode que plantean la conectividad como algo fundamental. Para algunas, como Zapier o Integromat, la integración es el core.

Por otro lado, el desarrollo de código es pura integración, a todos los niveles. La historia de la Ingeniería del Software se ha basado en la adopción de nuevas soluciones para adaptarse a las necesidades. Internet llevó esto a otro nivel, y hoy en día no se conciben sistemas de una cierta entidad que no impliquen la colaboración de varios actores (en algunos casos, miles de ellos).

Las herramientas NoCode solucionan problemas recurrentes en la construcción de sistemas de información, donde tendemos (con distintas intensidades, eso sí) a reinventar la rueda con cada nuevo desarrollo. ¿Cuántas veces has implementado un conector http o con una base de datos relacional? De hecho, cuando se piensa en la arquitectura de un sistema software, se le da una importancia capital a cómo se va a establecer la relación entre el núcleo del sistema y sus vecinos. Es en la conexión entre sistemas donde el software ha necesitado estar más estandarizado para ser interoperable. Y es aquí donde NoCode empieza a brillar. Muchas veces integrarse con una herramienta NoCode es como darle una llave maestra a tu software. En muchos casos más accesible que una API REST o un SDK.

Es, por tanto, fácil pensar en que los equipos de desarrollo de software empiecen a adoptar soluciones NoCode como parte de su set de herramientas para la construcción de sistemas.

El movimiento NoCode es fundamentalmente integrador

Más personas

Como hemos mencionado, NoCode es sobre todo un movimiento integrador. Pero no sólo de herramientas, también de personas. Uno de los principales problemas cuando se integran sistemas externos suele venir de la creación de dependencias excesivamente fuertes. Además del tradicional acoplamiento en desarrollo de software, se crean también dependencias humanas. Algunos temas como “Hay que pedírselo a desarrollo“, “Sólo lo puede hacer sistemas“, o peor aún, “Esto lo sabe Manolo, pero está de vacaciones“, son clásicos que se pinchan a diario en la discoteca del software tradicional.

Las herramientas NoCode pueden aliviar estas dependencias, permitiendo que una mayor diversidad de perfiles pueda tomar parte activa en el desarrollo y evolución del sistema. Una interfaz diseñada no sólo para informáticos así como un acotamiento bien definido del espacio de actuación pueden posibilitar un nivel de agilidad como no hemos conocido hasta ahora. Para los más recelosos a la hora de abrir esta puerta, simplemente hay que recordar que las dependencias excesivamente fuertes suelen ser fruto de un diseño mejorable, tanto de las herramientas como de la configuración de los equipos.

Las herramientas NoCode pueden aliviar dependencias, permitiendo que una mayor diversidad de perfiles pueda tomar parte activa en el desarrollo y evolución del sistema

Hay también algunas reflexiones interesantes, como la de Javi Santana en YesCode, que plantean la necesidad de “aprender a programar, aunque sea un poquito”. Es muy cierto que es necesario evangelizar en la cultura de la tecnología, pero en nuestra opinión el movimiento NoCode va precisamente en este sentido, y no en el contrario. Acerca a más implicados al código haciéndolo más accesible, o como poco supone una invitación a profundizar. Y, no nos engañemos, a los programadores no nos viene mal una visión externa y asomar el morro fuera de la cueva. Está bien que a uno le dé el sol de vez en cuando. NoCode favorece la colaboración en equipos cross-funcionales, algo que se ha demostrado más que positivo.

El papel del Ingeniero de Software

Los Ingenieros de Software jugamos un papel importante en este movimiento. El planteamiento de la integración de herramientas se podría simplificar como integración de datos. Cuando integramos herramientas normalmente queremos almacenar, notificar o accionar, siempre en base al intercambio de datos. Cuando un sistema empieza a crecer en complejidad, las decisiones con respecto a los datos se vuelven fundamentales, si no queremos encontrarnos con sorpresas nada agradables. Cuando tratamos con datos, queremos tener cerca a alguien que conozca conceptos como modelado, transaccionalidad, consistencia eventual, interfaces o eventos, por mencionar sólo algunos.

Es nuestra responsabilidad profesional conocer el movimiento y saber incorporar estas soluciones a nuestro quehacer diario

Adoptar NoCode sin conocimientos sobre sistemas tiene otros peligros. La dependencia excesiva de herramientas concretas, o de las soluciones que proponen (esto es algo más sutil) puede ser poco deseable si nuestro objetivo es construir un sistema que pueda evolucionar. El diseño de soluciones y arquitecturas flexibles es el mundo en el que vive el buen Ingeniero de Software. Como dijimos hace poco, es nuestra responsabilidad profesional conocer el movimiento y saber incorporar estas soluciones a nuestro quehacer diario. Llegará un momento en el que se nos consultará sobre esto, y habrá que contestar con conocimiento y, sobre todo, con honestidad.

¿Qué es code, después de todo?

Si lo pensamos, el único y verdadero código es el código binario: 101101.... Partiendo de esto, el resto son soluciones NoCode para que los humanos nos podamos apañar. La historia de la Informática ha consistido en ir elevando el nivel de abstracción, pero no para ser menos precisos, sino para tener un lenguaje en el que poder serlo aún más. Imaginemos dos escenarios:

1. Escribo Javascript, que es interpretado por un navegador y traducido en última instancia a 101101010...
2. Construyo un workflow en Integromat. Se ejecuta en su nube, pero al final también es 101101...

¿Cuál de los dos escenarios es más NoCode? El hecho de escribir el código Javascript en un navegador y que se interprete sobre la marcha es bastante NoCode, en el sentido de que el programador se abstrae de la mayor parte de la complejidad técnica. De la misma forma, podría darse el caso de que el workflow en Integromat tuviera especificados tratamientos de los datos bastante complejos. Son simplemente diferentes niveles de abstracción sobre los que definir una solución a nuestro problema. NoCode puede ser un nombre bastante atractivo, pero quizá en el fondo no estemos haciendo nada muy diferente a lo que hace un programador.

Conclusión

El futuro pasa por normalizar las herramientas NoCode dentro del propio proceso de desarrollo de software. Esto es algo a lo que los desarrolladores ya estamos acostumbrados, simplemente le damos otros nombres. El uso de librerías o herramientas desarrolladas por terceros son el pan nuestro de cada día en nuestro trabajo. La novedad que introduce NoCode es que estas herramientas están pensadas también para no-desarrolladores. NoCode, además de herramientas, también nos trae personas, y eso jamás puede ser algo malo ni excluyente. Todo lo contrario.