Una de las cosas que más daño ha hecho a esta profesión, junto con la idea de que un informático entiende de cualquier cosa alimentada por electricidad, son los generadores de aplicaciones. Como casi todas las cosas que realmente acaban causando daño, los generadores de aplicaciones no son inherentemente malos, el problema es el uso que se hace de ellos.

En mi vida profesional he pasado mucho tiempo dedicado al desarrollo de aplicaciones de movilidad profesionales, y aunque ahora que es un mercado masivo esto es mucho más sencillo, antes no era fácil encontrar programadores con conocimientos de este tipo de aplicaciones, lo que hacía que muchas empresas buscasen la ayuda de estas herramientas para poder desarrollar aplicaciones de movilidad con gente que no tenía mucha idea de cómo hacerlo.

Lo bueno

La idea de los generadores de aplicaciones ha sido siempre la misma: conseguir desarrollar aplicaciones sin tener que escribir código y, en muchas ocasiones, sin necesitar conocimientos de programación. Esto no es algo novedoso ni mucho menos. Las herramientas CASE que datan de los 70 y vivieron su máximo esplendor durante los 90 englobaban muchas herramientas para ayudar al desarrollo de software, y entre ellas unas de las más buscadas eran las que permitián desarrollar aplicaciones visualmente y sin tener que precouparse por cosas tan mundandas como la implementación.

Si lo piensas un momento, todo esto es completamente lógico y deseable. Los lenguajes de programación han ido evolucionando y elevando el nivel de abstracción (no es igual programar en ensamblador que en C, y no es lo mismo en C que en C#), y parece normal buscar herramientas que trabajen en un nivel de abstracción mayor que nos permita indicarle a la máquina “las especificaciones de problema” y obtener de ellas “un programa que las cumpla”.

Además, seamos realistas, hay cierto tipo de tareas que, si bien hace unos años hubiesen requerido un programación experto más o menos hábil para hacerlas, hoy en día se pueden hacer en dos minutos usando herramientas gráficas. Pensad por ejemplo en lo que se puede hacer con IFTTT y cómo hubiese sido hace unos cuantos años (no me quiero ni imaginar el script bash para hacer lo mismo). O pensad también en la creación de un prototipo rápido (aquí el problema es que ya sabemos dónde acaban esos prototipos de usar en tirar: en producción durante 10 años).

El malentendido: la gente de negocio

Entonces, si es una evolución lógica y además tienen su uso, ¿cuál es el problema? El problema es cómo se venden estas herramientas y cómo las entienden los que no saben de desarrollo de software.

La mayoría de estas herramientas prometen (y me he visto unas cuantas para documentar este post) que se puede hacer software rápidamente, sin programadores y con unos costes muy bajos. Además suelen refrendarlo con “casos de éxito” muy aparentes en sus webs. Cuando una persona que no conoce el desarrollo de software ve esto, lo que piensa es ¿para qué estoy contratando programadores, si cualquier persona que sepa manejar Office sería capaz de hacer ese trabajo?

Esto hace que el trabajo del programador quede muy devaluado a los ojos de la “gente de negocio” y no se aprecie la realidad del desarrollo de software, que va bastante más allá de arrastrar un par de controles en pantalla y enlazarlos a una base de datos. Es cierto que en esto también influye el nivel de muchos programadores y lo difícil que es encontrar programadores buenos, pero eso tiene solución, no te olvides de que la industria del software eres tú.

Por supuesto, al cliente no se le vende nada de esto. Al cliente se le suele decir que se utilizará una herramienta de última de última generación que permite abaratar costes alcanzando unas altas cotas de calidad, y que contamos con un equipo de expertos formados en la herramienta para sacar el máximo partido de ella.

La realidad es que la herramienta llega hasta donde llega, ni más ni menos, y que el experto formado en la herramienta es alguien que ha hecho, en el mejor de los casos, un video tutorial. El resultado, en la mayoría de los casos, es un cliente descontento con una aplicación que funciona a medias.

Por otra parte, estos generadores de aplicaciones no pueden (ni pretenden) tener la misma expresividad que un lenguaje de programación. Al fin y al cabo, se trata justo de eso, de aislar al “desarrollador” de la complejidad de la programación.

Esto hace que, lo que al principio era maravilloso porque permitió construir un prototipo en un par de tardes, a las 3 semanas se convierta en un infierno cada vez que aparece un requisito nuevo que no está cubierto por opciones estándar del generador de aplicaciones.

Generalmente, si el generador de aplicaciones está medianamente bien pensado, tiene alguna forma de crear tus propios “componentes”, programando en algún lenguaje normal (o en el pseudolenguaje de turno implementado por el generador), pero cuando llegas a ese punto te das cuenta de que realmente en añadir esa funcionalidad con las limitaciones que te impone el entorno tardarías casi tanto tiempo como en haber escrito la aplicación directamente con un lenguaje de programación al uso.

Nosotros también tenemos lo nuestro

Existe una vertiente más técnica (y quizá hasta más peligrosa) de los generadores de aplicaciones: los macro frameworks para hacer aplicaciones. No me refiero a AngularJS, ASP.NET MVC o WPF, sino a esos super frameworks que incluyen todo lo que necesitas para hacer una aplicación: sólo hace falta definir un par de clases y, automágicamente, te aparece un interfaz de usuario para editarlas y una base de datos para guardarlas (OJO: aquí no incluyo cosas como el scaffolding de ASP.NET MVC que está pensado para que tengas algo rápido de lo que partir y luego lo tires).

Lo peligroso de este tipo de macro frameworks (o requeteframeworks, que diría Rodrigo Corral) es que ya no es alguien “de negocio” sin conocimientos de desarrollo el que decide usarlo, sino que son los propios desarrolladores los que están convencidos de que es la mejor (y muchas veces la única) forma de hacer aplicaciones. Esto hace que sea mucho más complicado discutir su utilidad.

No conozco nadie (y yo el primero) al que no se le haya pasado por la cabeza diseñar algo así. Es muy atractivo tener una arquitectura estándar, replicable en todas las aplicaciones y que ahorre pensar. Sí, pensar, porque esa es la clave: te ahorra pensar.

Lo malo es que casi nunca hay dos aplicaciones iguales y trabajar con este tipo de macro frameworks se acaba convirtiendo en una experiencia muy poco productiva. Llega un momento en que consigues que todas las aplicaciones, aunque no tengan nada que ver entre sí, acaben acopladas unas a otras a través del framework.

Muchas veces, en lugar de ayudarte, el framework se interpone en tu camino, porque para ser reutilizable y genérico obliga a que existan ciertas clases en ciertos sitios y, aunque no las necesites para nada, no te queda más remedio que crearlas, terminando con una arquitectura extremadamente complicada sólo para guardar un cliente en la base de datos, o enviar un par de emails personalizados.

Conclusiones

Los generadores de aplicaciones tienen sus casos de uso y realmente pueden llegar a ser útiles, pero el problema es cómo se venden y lo que piensan algunos que son capaces de hacer.

Si necesito levantar una pared, busco a alguien que sepa poner ladrillos. No se me ocurre buscar un “generador de paredes” que yo pueda utilizar sin tener conocimientos de albañilería, porque sé que lo más probable es que la pared se me acabe cayendo. Otra cosa es que tenga un agujerito de un clavo y necesite taparlo; seguramente con un poco de masilla sea capaz de resolverlo yo solito.

Con un generador de aplicaciones pasa lo mismo, si sabes hasta dónde puedes llegar con él, utilízalo, estupendo, pero no pretendas venderlo como la solución a todos los problemas.

Aunque no nos guste admitirlo, los macro frameworks para desarrollar aplicaciones no son más que la versión “técnica” de un generador de aplicaciones y presentan problemas similares. No intentes encontrar una estupenda solución genérica porque, sencillamente, no existe. A veces es mejor repetir código en varios proyectos y poder adecuarlo a las necesidades de cada uno, que intentar encorsetarlos todos en una única solución.