Soy escéptico sobre el low-code

• Tengo una postura escéptica sobre el low-code
• Mientras trabajo en consultoría de software, con frecuencia me encuentro con clientes atraídos por anuncios que prometen tiempos de desarrollo rápidos y bajos costos de mantenimiento con low-code
• Hay varias razones por las que los clientes no quedan satisfechos

Limitaciones para las funciones personalizadas

• Las soluciones low-code cubren alrededor del 80% de los requisitos empresariales, pero el 20% restante no puede resolverse con las funciones base
• Los marketers de herramientas low-code afirman que ese 20% restante puede resolverse fácilmente, pero en realidad requiere una personalización considerable y a veces es imposible
• Las empresas deben elegir si las funciones base de la herramienta son lo suficientemente cercanas a lo que necesitan, o si intentarán hackear la herramienta para ajustarla a su caso de uso exacto

Limitaciones del pool de desarrolladores

• Las empresas a veces intentan hackear herramientas low-code para cumplir el 100% de sus requisitos
• Como resultado, terminan escribiendo mucho código personalizado para una herramienta específica o un lenguaje propietario, y hay muy pocos desarrolladores capaces de entenderlo
• Ahora la empresa, en lugar de reclutar del amplio pool de desarrolladores de lenguajes open source de uso general, debe encontrar mantenedores altamente especializados en esta herramienta

Problemas con las actualizaciones de la plataforma

• Es difícil actualizar software sin romper las integraciones conectadas
• Las herramientas low-code tienen que manejar código arbitrario para casos de uso para los que no fueron diseñadas
• Deberían poder hacerlo mediante contratos de API estrictos, pero en la práctica muchas veces veo código personalizado haciendo todo tipo de trucos internos

Caos en la estructura de la base de datos

• He visto empresas usar herramientas low-code en procesos donde el análisis preciso es indispensable
• Sin embargo, cuando se revisa el modelo de datos subyacente, está en un estado incomprensible: ¿qué significa user_attribute_47? ¿Si mueves un campo de la página 1 a la página 2 de la aplicación, los datos quedan en un campo separado?

Opinión de GN⁺

• El low-code es una herramienta prometedora que puede reducir la velocidad de desarrollo y los costos de mantenimiento, pero en el uso real pueden surgir problemas inesperados.
• En particular, cuando se requieren funciones personalizadas o se usan lenguajes de desarrollo dependientes de una herramienta low-code específica, se limita el pool de desarrolladores y se dificulta el mantenimiento.
• Las actualizaciones de las herramientas low-code y la complejidad de la estructura de la base de datos son factores importantes a considerar para la gestión de proyectos a largo plazo.
• Este artículo señala los puntos a los que hay que prestar atención al usar herramientas low-code y ofrece ideas interesantes al recomendar una evaluación cuidadosa de los casos de uso adecuados.

[ats62]

Creo que, hasta ahora, el concepto de no-code se ha aplicado de forma limitada en campos específicos.

Si aparece un servicio bien hecho que use LLM, me da la impresión de que antes que nada tendría que cambiar la tendencia, la corriente, la dirección... en fin, el propio concepto de no-code.

[quack337]

Conozco un caso de hace unos 10 años en el que se usó MS Access de forma útil.

En el sistema de información de la organización había una base de datos relativamente bien diseñada e implementada en MS SQL Server,
y las tareas cotidianas de OLTP también estaban relativamente bien implementadas.

Pero se había ido acumulando el descontento por la respuesta lenta y poco proactiva del departamento de TI ante solicitudes no rutinarias de consulta de datos e impresión de reportes.

Un empleado del área de negocio que manejaba bien MS Excel y Access mostró que podía importar a Access los datos de Excel descargados del sistema de información y, sin programar, implementar en apenas unas horas las funciones necesarias de consulta de datos e impresión de reportes usando Access.

[quack337]

El área de negocio pidió poder conectarse directamente desde Access a la base de datos, y el departamento de TI se opuso a exponer la base de datos del sistema de información a una red externa. Aun así, como la demanda del área de negocio era fuerte, se creó y expuso por separado una base de datos espejo con solo una parte de los datos.

Los empleados que sabían aprovechar bien las funciones de datos de Excel empezaron a usar Access en su trabajo tras solo unos pocos días de capacitación.

[tequila]

Creo que este artículo da en el clavo. Es una opinión personal, pero
cuando se usa una sintaxis especial -> se necesita una curva de aprendizaje y el mantenimiento se vuelve más difícil
cuando la UI simplemente reemplaza el código -> muchas veces termina siendo más cómodo programarlo directamente
cuando se convierte en una herramienta completamente no-code -> hay muchas limitaciones y se termina empujando a los usuarios a hacer hacks. Aumenta muchísimo la frecuencia de usuarios que generan comportamientos no previstos
Resultado: termina siendo una herramienta que no satisface a nadie.
La brecha entre planificación, desarrollo y usuarios es demasiado grande entre sí, así que parece un campo mucho más difícil de hacer bien de lo que uno imagina.

[GN⁺]

Opinión de Hacker News

• Diversas perspectivas sobre el low-code

  • Perspectiva de un desarrollador de plataformas low-code

    El low-code es fácil de vender. Se usa una estrategia que presenta al departamento de TI como el problema y aprovecha las frustraciones existentes. En las demos se muestran tareas simples de forma rápida. Pero es mejor no incluir la lógica central del negocio en low-code. Se asume que las tareas complejas se derivarán a sistemas especializados. Es útil en grandes empresas para equipos que tienen conocimiento técnico pero poca autoridad dentro de TI. El low-code resuelve muchos problemas con herramientas simples, pero escala mal y debe trabajar junto con un sistema central sólido.

  • Perspectiva de un SRE (ingeniero de confiabilidad del sitio)

    Es escéptico respecto al low-code. Tiene un manejo deficiente del código fuente y poca documentación. Requiere mucho código personalizado, pero con baja reutilización. Exige runtimes propietarios y es difícil de monitorear. En la práctica, no ha visto casos donde los ingenieros hagan el trabajo y los no ingenieros lo usen. Herramientas como Looker pueden integrarse con el código fuente, pero aun así las siguen usando ingenieros. Comprime la complejidad, pero prefiere plataformas que puedan personalizarse y extenderse según sea necesario.

  • Perspectiva sobre la plataforma low-code de Microsoft

    Le interesaba la plataforma low-code de MS, pero parece construida de forma compleja sobre O365 y Azure. La interfaz de usuario es deficiente y, a largo plazo, las pérdidas por problemas de usabilidad podrían ser mayores que cualquier ahorro de costos.

  • Experiencia de negocio migrando soluciones de base de datos/formularios de MS-Access

    Construyó un negocio convirtiendo soluciones de MS-Access creadas por no desarrolladores o usuarios finales sin pasar por el departamento de TI en verdaderas aplicaciones cliente/servidor en .net. Las soluciones low-code son útiles para resolver algunos problemas o hacer funcionar un POC, pero pueden generar problemas cuando hace falta escalar o adaptarse.

  • Perspectiva de un desarrollador del constructor de sitios web SQLPage

    Las soluciones low-code deberían tener una vía de escape para interactuar con APIs externas de "high-code". En SQLPage esto se ofrece mediante sqlpage.exec. Existe el problema de que las actualizaciones de una plataforma low-code pueden romper implementaciones personalizadas. La mayoría de las herramientas low-code toman los datos como rehenes, pero SQLPage agrega una capa sobre una base de datos que el usuario todavía puede controlar por completo.

  • Opinión en contra de las herramientas low-code de nivel empresarial

    Está en contra de las herramientas low-code que usan las grandes empresas. Las grandes empresas deberían poder costear equipos de desarrollo adecuados, junto con planificación y organización. No es el código lo que genera costos, sino los malos desarrolladores tomando malas decisiones con malas herramientas.

  • Perspectiva sobre el low-code y las capas de abstracción

    El "low-code" tiene una superficie menor de código con la que se puede interactuar directamente, pero en realidad hay mucho código oculto. Las capas de abstracción son poderosas cuando encajan bien con su propósito, pero pueden causar problemas cuando tienen fugas o no son adecuadas. En general, el low-code abstrae código ajustado a casos de uso específicos, pero en la práctica requiere experiencia en un dominio concreto.

  • Experiencia construyendo un MVP con Bubble/Airtable

    Recibió una cotización de un equipo ucraniano para construir un MVP, pero contrató a un pasante y creó el producto en dos meses usando Bubble/Airtable, consiguiendo clientes de pago en menos de 6 meses. Durante casi dos años no encontró una razón para migrar a un stack tradicional.

  • Historia de terror desarrollando cursos de aprendizaje con low-code

    Una empresa importante desarrolló cursos internos de aprendizaje para personal de marketing y ventas usando un paquete de software low-code para crear cursos. Años después surgió la necesidad de actualizar los cursos, pero aparecieron problemas porque ya no tenían el software usado para desarrollarlos ni herramientas capaces de hacer el trabajo.

  • Pregunta sobre la posibilidad de control de versiones en implementaciones low-code

    Se cuestiona si las implementaciones low-code pueden ponerse bajo control de versiones, si es posible encontrar la causa de un problema cuando algo falla, y si se puede hacer rollback a un commit específico usando herramientas gratuitas. En la mayoría de los casos, estas funciones no existen, por lo que no son adecuadas para usos serios.