Los desarrolladores suelen malinterpretar el movimiento no-code, pensando que significa "sin programadores" o "no apto para programadores". Yo solía ser uno de ellos. Como desarrollador, veía el "no-code" como una amenaza o descartaba estas herramientas como algo inferior, algo a lo que solo recurres si, bueno, no sabes programar. Pero hay un secreto a voces detrás de la actual generación de herramientas "no-code": todo es código.
Las herramientas no-code generan código. Las herramientas no-code funcionan sobre montañas de código. Las herramientas no-code pueden incluso interactuar con tu código. Siguen requiriendo usuarios técnicos: personas capaces de depurar, de pensar en abstracciones y, sobre todo, de saber cómo combinar las herramientas adecuadas de la forma correcta para generar valor empresarial.
Si piensas que ese conjunto de habilidades suena a lo que hacen los desarrolladores, tienes razón. Al igual que "serverless" significa "no son tus servidores", no-code simplemente significa "no es tu código".
La economía de las API + "no-code" = La economía de las GUI
Quizás hayas oído hablar de la economía de las API —la idea de que, a medida que el software se apodera del mundo, surge toda una generación de empresas de software especializadas en resolver problemas complejos para que tú no tengas que hacerlo. La persona promedio de la calle nunca oirá hablar de Stripe o Twilio, pero puede que sean clientes de algunas startups que, a su vez, son clientes de Stripe o Twilio para pagos o comunicaciones.
Donde antes los desarrolladores eran responsables de toda la pila de código e integraciones necesarias para hacer posibles estas capacidades, las empresas de API hacen que añadir funcionalidades comoditizadas sea tan fácil como insertar unas pocas líneas de código. Esto tiene sentido en múltiples dimensiones: transforma un coste elevado, fijo, inicial e incierto en un gasto variable, diferido y predecible, y es probable que un servicio especializado sea más robusto y barato (debido a la escala) que uno escrito por uno mismo. Esto es enormemente beneficioso para ambas partes, lo que ha dado lugar a toda una economía de API floreciendo para cada "problema difícil" imaginable:
Un resultado (¿imprevisto?) de la economía de las API es lo mucho que ha facilitado las cosas también a los desarrolladores individuales. De repente, si entiendes HTTP y REST, tienes acceso a las capacidades de búsqueda de nivel de doctorado de Algolia, o a las relaciones bancarias nacionales forjadas por Plaid. Esto no es una amenaza para los desarrolladores, ni es algo que los desarrolladores "reales" no usarían; simplemente redefinió en qué consiste el trabajo. En lugar de realizar el mismo trabajo pesado y poco diferenciado que hace cualquier otro desarrollador, ahora puede centrarse en escribir solo el código central que la empresa necesita para cumplir con su propuesta de valor única, dejando que otros especialistas se encarguen de la suya. Con esta reducción en el área de responsabilidades, cabría esperar alguna amenaza del tipo "las API nos están quitando el trabajo" o "las plataformas nos están quitando el trabajo". Sin embargo, los salarios de los desarrolladores subieron, no bajaron, con esta transformación de la economía de las API.
Este es el contexto con el que ahora abordo el actual movimiento no-code.
Donde antes los desarrolladores eran responsables de escribir el código para vincular la lógica empresarial y varias API, ahora pueden hacerlo visualmente. Cuando miras la interfaz de Zapier y ves a personas manipulando literalmente lógica booleana para realizar su trabajo, es difícil negar que están programando su lógica empresarial en términos que la máquina entiende. Simplemente no parece la idea de programación que tiene un programador.
No es ningún secreto que las interfaces gráficas de usuario (GUI) son más intuitivas y fáciles de usar para más personas que la documentación técnica de las API, que requiere recursos de ingeniería adicionales para escribir el código necesario para aprovecharla. Así que la próxima generación de herramientas apuesta por esta idea: ofrecer su funcionalidad principal con una GUI para manipulación directa, además de interconectarse con otras herramientas. Incluso empresas muy centradas en los desarrolladores como Netlify, donde trabajo, invierten mucho en GUI, con un extenso sistema de diseño para arrancar. Un beneficio adicional de centrarse en la GUI, particularmente con aplicaciones web, es la capacidad de usar el software en dispositivos móviles, la plataforma informática principal de nuestro tiempo.
Llamaré a esto la economía de las GUI. Al igual que el movimiento de las API antes que él, permitirá que un círculo concéntrico más amplio de personas (que no se identifican como desarrolladores, pero que son técnicos) construya e interactúe con el software, y sin embargo será menos una amenaza para los desarrolladores que un facilitador. Lo que me lleva a...
Diseña interacciones y animaciones sin escribir código
Crea interacciones y animaciones complejas sin tener que tocar ni una línea de código.
Herramientas de desarrollo visual
Al principio, un desarrollador podría resistirse a la idea de que las herramientas visuales pueden ayudar a programar. Pero una vez que las buscas, las ves por todas partes.
Entornos de desarrollo visual
Con una cuota de mercado del 51%, el entorno de desarrollo más popular hoy en día es VS Code, a pesar de haber sido lanzado recién en 2015. ¿Qué explica su meteórico ascenso en popularidad sobre editores de código más simples como Notepad++, Atom y Sublime? Entre otras cosas, ofrece una interfaz de apuntar y hacer clic para buscar, navegación de archivos, sugerencias de tipos, personalización de ajustes, adición de extensiones, etcétera. Eso es lo que este y otros IDE completos ofrecen sobre herramientas más simples. De hecho, Dark Lang combinó recientemente IDE y lenguaje, llevando el IDE y la metáfora de programación visual a un nivel aún más alto al garantizar que no puedes escribir código inválido porque el IDE no te lo permitirá. Nadie discute que esto sea programación ilegítima.
Máquinas de estados visuales
Del mismo modo, existe un movimiento generalizado para adoptar diagramas de estado y máquinas de estados diseñadas visualmente que controlen la lógica de las aplicaciones. Esto permite visualizar transiciones de estado complejas y hace que las lagunas debidas a una mala planificación sean dolorosamente evidentes. Los cambios en la lógica de negocio derivados de nuevos requisitos se añaden, validan y trasladan a la capa de vista de forma intuitiva y coherente. Con la herramienta xstate Viz creada por David Khourshid, puedes simular visualmente cualquier transición y efecto secundario en tu máquina de estados. Nadie discute que esta sea una forma menos legítima de modelar máquinas de estados; de hecho, todo lo contrario.
Interfaces de línea de comandos visuales
A primera vista, las "interfaces de línea de comandos visuales" parecen un oxímoron. ¿No son las interfaces de línea de comandos (CLI) el polo opuesto de las GUI? Últimamente, esta línea se está difuminando de formas creativas e interesantes. La Vue CLI creada por Guillerme Chau marcó el camino al construir una capa de aplicación de escritorio completa sobre su CLI, para facilitar la capacidad de descubrimiento y la visualización. Pero el deseo de representar gráficamente el estado de ejecución del código y las opciones es tan antiguo como las propias CLI, desde los spinners más básicos hasta formularios y plantillas navegables e interactivos o la creación de motores de diseño y renderizados interactivos completos con React. ¡Nadie discute que esta sea una forma menos legítima de ejecutar código!
Edición de interfaces visuales
La experiencia "lo que ves es lo que obtienes" (WYSIWYG) ha tenido una historia complicada. Como se trata de un problema especialmente espinoso, los primeros intentos como FrontPage y Dreamweaver no eran precisamente buenos generando código legible y fácil de mantener. Pero las tecnologías web han avanzado mucho desde entonces: Firebug permitía editar sitios directamente hace 12 años, tiene un clon moderno en el proyecto Visbug liderado por Adam Argyle, e incluso cuenta con una solución integrada en la API de navegador document.designMode. Por supuesto, Webflow lidera la vanguardia en cuanto a herramientas de diseño y creación web sin código, incluyendo incluso soluciones integradas de CMS y comercio electrónico. ¡Nadie debería discutir que esta es una forma menos legítima de escribir interfaces de usuario!
En el centro de todo esto se encuentra la noción de experiencia del desarrollador. Al fin y al cabo, los desarrolladores también somos humanos: respondemos de la misma forma positiva a las interfaces gráficas que el resto de nuestros usuarios.
Si aprendemos a tratar las herramientas visuales como aliadas en lugar de como enemigas, pueden convertirse en enormes potenciadores de productividad tanto para nosotros como para nuestros amigos que no se dedican a la programación tradicional.
En todo caso, deberíamos ser mejores que ellos en esto, porque tenemos formación profesional para entender cómo diseñar y mantener sistemas, y sabemos qué preguntas hacer para averiguar dónde empiezan y terminan las abstracciones.
Creación sobre código
El viejo y cansado debate en la programación es el de "convención sobre configuración" o viceversa. Lo que este debate pasa por alto es que estas son, en mayor o menor medida, formas evolutivas de trasladar la responsabilidad del código entre el creador de la herramienta y el usuario de la misma. Puedes hacerlo mal o puedes hacerlo bien. Al final del día, sigue siendo código, y al usuario final no le importa realmente qué has usado ni cuánto has escrito.
Se han vertido galones y petabytes de tinta física y digital sobre niveles de abstracción progresivamente más altos en la programación, desde los primeros días de GOTO hasta la división imperativo/declarativo, o el movimiento más reciente de los paradigmas orientados a objetos a los funcionales.
Hemos superpuesto código sobre más código para hacerlo más fácil, seguro y expresivo, pero a pesar de todo esto, no ha habido una mejora objetivamente medible en la productividad del desarrollador desde el punto de vista del usuario.
Quizás hemos llegado al límite de lo que pueden hacer las abstracciones crecientes dentro del código. Para pasar al siguiente nivel, tenemos que abstraer por encima del código. Quizás en lugar de poner el código en el centro de nuestro universo, con más código como solución a cada problema, deberíamos enfatizar la creación y considerar todo lo que nos ayude a llegar allí.
El "no-code" no es solo para creadores de sitios web y aplicaciones. También presenta tremendas oportunidades para los creadores de herramientas de desarrollo.
Trabajo en Netlify, que ayuda a los desarrolladores a crear y alojar sitios y aplicaciones JAMstack. Netlify no se considera clásicamente una herramienta "no-code", porque casi con toda seguridad necesitas programar para crear la mayoría de los sitios que la gente hace con Netlify. Sin embargo, desde la perspectiva de los desarrolladores front-end, que constituyen la mayoría de la audiencia de Netlify, es "no-code" en un aspecto muy importante: el back-end. Netlify asume la responsabilidad de contratar y gestionar una plataforma, un producto y un equipo de soporte de clase mundial que gestiona despliegues de Kubernetes, invalidación de caché de CDN y respuesta a incidentes. Por otro lado, todas las preocupaciones del backend relacionadas con el despliegue continuo, la configuración de una CDN, la obtención de un certificado SSL para un alojamiento HTTPS seguro, la configuración de dominios personalizados y una docena de otras prácticas recomendadas importantes pero aburridas, se abstraen, permitiendo a los desarrolladores front-end crear y desplegar sus sitios a la par que equipos full-stack de clase mundial.
Si eres un emprendedor que busca marcar la diferencia sirviendo a los desarrolladores, un enfoque fiable para ganar tracción es permitir que un segmento desatendido de creadores haga su trabajo, solo que mucho más fácilmente, con una interfaz "no-code" para toda la complejidad incidental que suele interponerse en su camino.
No todo es color de rosa
No quiero que te lleves la impresión equivocada de que todo es automáticamente mejor con una capa "no-code". Este movimiento aún está en pañales y quedan muchos problemas difíciles por resolver en este cambio de paradigma.
Siempre tendrás más potencia programática con código que con interfaces gráficas, aunque ya hayamos empezado a descifrar cómo programar el flujo de control en ellas. ¿Cuándo es mejor quedarse en las interfaces y cuándo es mejor bajar, salir o exportar a código? ¿Podemos hacer que sea un proceso reversible en lugar de irreversible?
La capacidad de descubrimiento es más sencilla en las interfaces gráficas, pero se sacrifica densidad de información, expresividad y, a menudo, velocidad. ¿Cómo evoluciona el diseño de aplicaciones en la era de las herramientas no-code? Muchas herramientas de código funcionan sin conexión, mientras que las interfaces web no-code a menudo no lo hacen por defecto. ¿Qué tan importante es esto?
Desarrollar interfaces gráficas es costoso (la frenética innovación en frameworks frontend es prueba de que aún no hemos terminado), por lo que las herramientas no-code, que a menudo son interfaces para crear interfaces, son aún más caras y difíciles de construir. ¿Cómo podemos hacerlas más simples, baratas y accesibles por defecto?
Todas estas son preguntas sin respuesta y espero con ansias todo lo que descubriremos sobre ellas en los próximos años.
Desarrolladores: denle una oportunidad al no-code
Confieso que mi título fue un poco sensacionalista, pero si eres desarrollador, gestor de producto o fundador técnico, probablemente te hayas visto reflejado en algunos de estos debates sobre la percepción del "no-code" y los retos y oportunidades que presenta. Sobre todo, quería demoler de una vez por todas la idea errónea de que "no-code" significa que no hay código involucrado o que no es para quienes saben programar. Creo que este movimiento es una victoria tremenda para todos, tanto para programadores como para "no programadores", y cuanto antes nos demos cuenta, más productivos seremos usando la tecnología para resolver problemas reales.
