Cuánto daño han hecho… Los generadores de aplicaciones

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.


16 comentarios en “Cuánto daño han hecho… Los generadores de aplicaciones

  1. La verdad los generados de aplicaciones no solo crean una confusión para los jefes que no tienen noción clara de proyectos, ya que el venden como una herramienta poderosisisisma que le permitira tener proyectos en menos tiempo y que no es necesario pensar.

    Ejemplo son muchas aplicaciones como codesmith y otras que prometen generar una aplicacion en minutos y no necesitas un programador o en todos los casos en vez de aportarle al programador una solucion se vuelve un problema por varias razones.

    1) El jefe cree que al tener una aplicacion de generacion de aplicaciones el programador necesita menos tiempo para realizar las tareas … (TODO LO CONTRARIO) deberia en caso extremo que se fuera a usar esa aplicacion de generacion, pues tener mas tiempo para la arquitectura, pero no el jefe piensa que ahora si el tiene una aplicacion que le genera el proyecto el programador si hacia un promedio de 4 proyectos cerrados al año (cosa que no es asi) pues ahora tendra un promedio de casi 12.

    Lo peor es que luego nos tocan proyectos, en el cual se utilizaron generadores, siempre termina o en migración o en alguien que tiene que perder su familia para darle soporte a esa aplicación.

    Una cosa es utilizar aplicaciones de generacion de clases, metodos repetitivos usando mygeneracion o tt o wherever, pero no piensen que pueden tener sistemas complejos con eso!!!!

    Un saludo!

  2. Juan María Hernández dijo:

    Gracias por tu comentario, Dany.

    Además, creo que lo último que dices es muy importante: no hay que confundir un generador de aplicaciones, con la automatización de ciertas tareas.

    Si necesitas generar mucho código “similar”, es bueno tratar de automatizar el proceso (aunque aún mejor es no tener que generarlo y mantenerlo, claro).

  3. Juan María Hernández dijo:

    Alberto, no conozco mucho LightSwitch, pero por lo que he visto en la MSDN, diría que sí, es un generador de aplicaciones.

  4. ¿ Incluirías SugarCRM,Wordpress,Magento,Prestahop como generadores de aplicaciones? es para entender a que te refieres.

  5. Juan María Hernández dijo:

    Para mi son cosas distintas. WordPress, Magento, etc. son gestores de contenido muy personalizables o, si lo prefieres, plataformas sobre las que desarrollar aplicaciones web. No digo que me gusten más o menos (también se puede abusar de ellos), pero creo que son algo más específico y con un caso de uso más definido.

  6. Pingback: Cuanto daño han hecho los generadores de webs | Javierh.com

  7. yo estoy a punto de enloqueser en mi trabajo uso un software desarrollado bajo un generador de aplicaciones y para aser una accion tengo que dar una buelta al mundo estoy arttooo pero mi jefe no quiere aserme caso dise que yo soy el maleta,….

  8. Es una frontera muy fina… Depende de cuánto pretenda suplir la plataforma al programador y de cómo se use. Hay herramientas de modelado que no son tan terribles, aunque a mi personalmente no me gusten demasiado.

  9. La idea es que el programador solo sea necesario en pequeños cambios al código, más la mayoría del trabajo, sino todo, lo deberá estar haciendo el analista que traduce los requerimientos del negocio en la plataforma de modelamiento INTEGRANOVA, la cual a su vez, se encarga de crear todo el código de la aplicación

  10. No conozco INTEGRANOVA, pero tal y como lo describes, suena peligroso.

    Al final en lugar de tener un programador con un lenguaje de propósito general, tienes un analista con un “lenguaje” de muy alto nivel (la herramienta de INTEGRANOVA).

    Mientras los problemas a resolver encajen con esa herramienta, estupendo, te has “ahorrado” un programador, a costa de que el analista tenga que pegarse con la herramienta para plasmar su análisis.

    En cuanto esa herramienta no te permita hacer lo que necesita el cliente, o asumes el coste de abandonarla, o acabarás con problemas a nivel funcional (no le podrás dar al cliente lo que realmente necesita) y a nivel económico (hacer que el programador te parchee el código o la aplicación o lo que sea que genere INTEGRANOVA puede resultar más caro que programar directamente fuera de esa plataforma).

  11. Jesús, le acabo de echar un vistazo a la documentación de la web (http://www.care-t.com/Evaluation/downloads/Tutorial_00/Tutorial_00_Hello_World!.pdf) y, definitivamente, no soy muy partidario de ese concepto.

    No digo que no haya gente que le pueda sacar partido, pero a mi generar toneladas de código que no sabes si va a ser necesario o no, que nadie entiende muy bien por qué está ahí, y que luego alguien tiene que mantener, no me parece una buena opción.

  12. Jonny Palazuelos dijo:

    Hola a todos los que puedan estar leyendo este post, estaba apunto de usar un generador de aplicaciones cuando me encontré esto.

    Creo que varios de los que escribieron pueden ser programadores, tengo un pequeño negocio donde vendo alrededor de 100 productos diferentes , a veces menos. Quiero hacer una aplicación para poder llegar a más gente, espero alguien pueda contactarme para hacer alguna propuesta y quiera ayudarme, palazuelosjp@gmail.com

    Estaré esperando. Saludos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>