Pages Menu
Categories Menu

Posted by on Nov 14, 2013 in General | 18 comments

¿Se van a necesitar cada vez MENOS programadores?

Cada vez necesitamos más y más software, pero ¿también, al mismo ritmo, vamos a necesitar cada vez más y más programadores? O, visto desde otro punto, ¿habrá suficientes programadores para desarrollar tantas aplicaciones como la sociedad necesita – necesitará?, y sino los hay ¿aparecerán nuevas maneras de crear software sin necesidad de expertos en programación?

Llevo años dándole vueltas a una predicción triste, apocalíptica, que de siempre me ha rondado por la cabeza, pero que no había tenido, y quizás aún no tengo, lo suficientemente estructurada mentalmente como para poder escribirla: ¿llegará el momento en que no sea necesario programar? Bueno, dicho así, el planteamiento es demasiado ambiguo y genérico, déjame que te lo concrete un poco más: ¿llegará el momento en que no necesitemos (tantos) programadores para programar o crear aplicaciones?

La industria lleva años invirtiendo mucho dinero para que no se necesiten (tantos) programadores para crear aplicaciones

Algunos lo justifican en lo que llaman la “ecuación imposible”, aquella que dice que el número de programadores crece lentamente, e incluso en algunos países el interés por las carreas técnicas decae (véase como ejemplo el famoso post sobre el caso de España, el de ya no gusta estudiar informática), mientras que la necesidad de aplicaciones software crece exponencialmente.

Así que, nuestra profesión, la informática, la ingeniería del software, lleva años, muchos, intentando que llegue el día en que no programemos. Suena un poco a suicidio. Pero así es. Esta profesión tiene esas cosas. Si hay un sueño dorado, perseguido desde siempre por miles de investigadores en software, este es… que no se tenga que programar (o qué sea tan fácil que esté a disposición de casi cualquiera). Harakiri.

Mientras lees esto deberías ser consciente de que hay miles de profesionales (y millones de euros) intentando que no programes más, o que no programes como hasta ahora lo hacemos. O que pueda programar (o más concretamente crear) aplicaciones cualquier persona.

Así que, mirando al futuro, se auguran dos posibilidades o soluciones para resolver la ecuación imposible:

a) Incrementar la productividad de los programadores (se entiende que mejorando técnicas, metodologías  y herramientas, no, como hacen algunos por aquí, haciendo que trabajen más horas), para que puedan crear más software.

b) Facilitar la programación (o más concretamente “la creación”) de aplicaciones a no-programadores de profesión. En este contexto, un programador profesional es alguien que en su trabajo se dedica a la programación, por lo general usando los típicos  lenguajes de programación, un Java, C #, C++, etc., puede que el futuro nos augure un crecimiento exponencial de lo que algunos llaman… la era del “end-user programming”  gente que crea programas pero sin ser esta su profesión principal, químicos con formación en programación, abogados con formación en programación, médicos, economistas, etc. (alguno pensará que esto ya pasa todos los días, pero me refiero a que los “no programadores de profesión” programen cosas controlables)

Y para los anteriores, por iniciativas que no sea…

Pasado, presente y futuro de todo lo ingeniado por el hombre para que llegue el día en que no se programe

Este largo camino de investigación, que se remonta más allá de los 70, ha tenido grandes éxitos, y grandes fracasos, pero, desde luego, mucha constancia, e inversión.

Lenguajes de más alto nivel y generadores de código

En su día se dio un salto dejando atrás el ensamblador, introduciendo los lenguajes de alto nivel, que no evitaron programar pero simplificaron la tarea. Otro salto fue  la creación de programas como el Excel, que evitaron tener que programar (o facilitaron la programación) de muchas funciones de cálculo, dejándolas accesibles a muchos perfiles.

Desde hace años, la comunidad que investigaba la creación de herramientas CASE parecía que podía lograrlo, generaban código desde lenguajes gráficos como UML… pero no fue suficiente.

Otras comunidades más recientes como las de MDD, MDA, DSL, y similares, también lo han perseguido. Perseguían, y persiguen, la generación automática, y la creación de aplicaciones por parte de personas sin grandes conocimientos en programación.

Pero hasta la fecha las anteriores iniciativas no han funcionado del todo bien principalmente, principalmente por dos razones: o bien la curva de aprendizaje era demasiado grande o bien el código generado era de muy mala calidad o era muy difícil de mantener.

Concretamente, no han funcionado bien en grandes desarrollos, porque en lo que refiere a pequeños desarrollos han crecido considerablemente, con mucho éxito, las herramientas disponibles para crear, por ejemplo, apps móviles para las distintas plataformas existentes en el mercado sin conocimientos previos de programación: Creapp, Apps Builder (aquí dejo un listado mayor).

“Paquetiza” todo lo que puedas…

Y, desde una aproximación distinta, otras estrategias orientadas a crear paquetes estándar fácilmente parametrizables, como las de reducir al mínimo la programación en la creación de contenidos, con plataformas como wordpress, que ha dejado al alcance de cualquiera disponer de una plataforma de gestión de contenidos casi sin conocimientos técnicos. Personalmente, y es bastante lógico, cada vez te encuentras más con gente sin conocimientos formativos programación desarrollando plugins para este tipo de plataformas.

Toda infraestructura de programación “paquetizala” también, y si es en cloud… mejor

Movidos por esta inquietud, o quizás por estos miedos, hace unos meses Nacho Suarez y yo comenzamos un trabajo de estudio de plataformas en cloud cuyo objetivo fuese que te olvidases de todo lo que te puedas olvidar a la hora de empezar a programar, es decir, que te olvidases de instalar IDEs, herramientas de control de versiones, integración continua, entornos de testing, etc.

Y, aunque aún no hemos terminado nuestra labor, la lista de iniciativas, de mayor o menor calado no deja de sorprendernos.

Concluyendo…

Si bien, si miramos atrás, no podemos negar que muchas cosas que antes requerían de un programador, hoy en día están al alcance de cualquiera, aun queda mucho para que desaparezca “el programador”, aunque solo sea porque se necesitan programadores para crear plataformas para los “programadores no profesionales”.

Aun así, yo, hablando en términos de futuro profesional, me andaría con un ojo puesto en este tema, puesto en el futuro, en tres o cuatro años, intentando posicionarme en entornos progesionales de “más difícil paquetización”.

Y en el posible impacto que este tipo de iniciativas pueden tener en ciertas dedicaciones profesionales de la programación de hoy, y como esto se puede unir a otra gran amenaza para la profesión, especialmente en países como España, y que viene de aquello  que hablamos en el post de vamos a competir por un puesto de trabajo con profesionales de todo el mundo, dos temas que dentro de unos años pueden cambiar totalmente el panorama profesional del mundo del software.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

18 Comments

  1. los dirigentes de la sociedad nos han guiado a este estado de sobreinformación (sosa y superficial, por cierto) porque, entre otras cosas, es un negocio. La tecnología es una gran negocio que exige muchísima mano de obra. Ahora mismo hay un montón de trabajos obsoletos, la población ha sido reconvertida en usuarios/programadores. No hay planes de eliminar a los programadores, al revés.
    Un último consejo a todos los que están en el paro: haced un curso de programación para móviles pero ya: no dejéis pasar la ola.

  2. Hola Javier,

    Te dejo una pregunta como respuesta a tu artículo:

    ¿Quién va a realizar las aplicaciones que faciliten la creación de programas a personas no-programadores?

    Si pensamos en un programador como una persona que introduce instrucciones a una máquina para realizar una tarea, mientras existan las máquinas SIEMPRE serán necesarios programadores. Y si consideramos máquinas programables a dispositivos como smartphones, tablets, incluso relojes inteligentes, yo creo que en un futuro se demandará una mayor cantidad de ellos.

    Aún así, es mi opinión personal. Y si, soy programador 😉

    Un saludo,

  3. Hola,
    Dos cosas por si no quedaron claras, yo hablo de MENOS programadores, no de la DESAPARICIÓN de los programadores. Y al final del post comentaba “que queda mucho para que desaparezca “el programador”, aunque solo sea porque se necesitan programadores para crear plataformas para los “programadores no profesionales”.

    Gracias por los comentarios!

  4. Hola.

    Yo creo que no se van a necesitar menos programadores sino que se van a necesitar más programadores, pero mucho mejor formados, que no sean simples programadores sino que se involucren desde el principio de la creación del sistema hasta el final, o ¿no es eso de lo que tratamos en este blog?.

    Cualquiera que aprenda “sólo” a programar (me acuerdo del anuncio de Telefónica donde aparecía el mono “Aurelio” aprendiendo a programar) no le va a servir de casi nada, ya que cada vez más se requiere del programador que aporte un plus al proyecto, se le requiere más implicación desde la definición hasta la entrega.

    Programar no es diseñar sistemas de información. Creo que la ingeniería informática no es sólo programar. Ni mucho menos.

    Efectivamente existen muchos programadores que han llegado a esta profesión de rebote y programan, pero de aquella manera.

    Cada vez se demandan sistemas de información con más calidad, porque el mismo usuario final conoce cada vez mejor estas herramientas y ya no admite cualquier cosa. Creo que por ello se demandarán cada vez más, mejores profesionales de la ingeniería informática, porque para programar vale cualquiera, pero no para construir sistemas de información de calidad, seguros, eficientes, mantenibles y fácilmente adaptables y escalables.

    Saludos.

  5. En proyectos pequeños y medianos las necesidades son muy similares. Me atrevería a decir que el 80% por ciento de las aplicaciones tienen requerimientos muy parecidos (tiendas on-line, redes sociales, etc) así que creo que en este tipo de proyectos la programación será cada vez más residual. El triunfo de los CMS como WordPress lo demuestran.

    Otra cosa son los grandes proyectos… ahí se puede automatizar una parte (de hecho, muchas necesidades habituales como accesos a bases de datos, programación de pantallas de usuario, etc, ya cuentan con muchos automatismos en las grandes organizaciones), pero ahora mismo creo que el momento en que un banco, por ejemplo, pueda realizar aplicaciones sin apenas programar está muy lejos.

  6. Discrepo de la visión planeada aquí.
    Como sabe bien Javier soy de esos que entrarían en el grupo de los que persiguen quimeras en el mundo MDD. 😉

    Automatización no está reñida con falta de calidad, al contrario, permite asegurarla en ciertos dominios.

    Como contrapunto ese artículo, invito a los lectores a leer
    End User Programming for Mobile Apps y aun más, a probar uno de estos sistemas modernos y sacar sus propias conclusiones sobre el nivel de madurez de este tipo de herramientas.

    No olvidemos que “End User Programming” no es algo nuevo. El ejemplo mas accesible de “End User Programming” es por ejemplo, cuando un contable usa una hoja de calculo para hacer su trabajo. Crear una macro que suma es una primera “forma de programación” sin un desarrollador convencial al mando.

    Saludos.

  7. En particular Javier, ante la afirmación:

    “Pero hasta la fecha las anteriores iniciativas no han funcionado del todo bien principalmente, principalmente por dos razones: o bien la curva de aprendizaje era demasiado grande o bien el código generado era de muy mala calidad o era muy difícil de mantener.”

    Discrepo por dos motivos:

    1. Hoy ya comienzan a aparecer los sistemas donde la curva de aprendizaje es muy pequeña. Usuarios pueden crear aplicaciones en 5 minutos (en un dominio reducido). Todo es cuestión de elegir bien el dominio y el nivel de abstracción.

    2. La calidad de código en esos sistemas puede ser tan buena como queramos: siguen las mejores prácticas de la industria en cuanto a calidad y mantenibilidad. No hay escusa para que un generador de código no proporcione un código excelente. Porque todo generador de código está basado en motores de plantillas. Si tenemos una versión “manual” mejor, podemos tomarla como base para mejorar la plantilla en un proceso iterativo de mejora continua tanto como deseemos hasta quedar satisfechos.

    • Al menos en lo de los 5 minutos, le doy la razón totalmente a Pedro. Yo estuve utilizando Radarc, para generar .NET, antes de saber programar medianamente bien en .NET y monté prototipos de aplicaciones en un día.

      De hecho, en mi caso, el código generado por la herramienta me sirvió para aprender implementaciones de ciertas técnicas, configuraciones o diseños en .NET para los que no tenía ejemplos accesibles (¡bendito código de inversion de control!).

      Y como dice en el 2º punto: la calidad depende de quién genera el generador. Si tienes un proveedor de calidad para tu generador de código, sabes que su nivel de calidad y sus mejoras en el tiempo se van a traducir en mejores soluciones concretas para tus diseños, así que la baja calidad vas a tenerla sólo si te conformas con una herramienta pobre o poco evolucionada.

  8. Probablemente lo que se necesiten sean menos “picadores” no menos programadores.

    De echo como se comenta hay muchos dominios que están muy trabajados, (comercio electrónico, gestores de contenidos, de portales,…) con lo que el aportar algo ahí es muy difícil.

    También hay muchas herramientas que facilitan tareas (acceso a datos, construcción de interfaces,…)

    Pero seguirá existiendo la necesidad de integrar sistemas y aplicaciones.

    Lo que probablemente se reduzca es el tirar líneas y líneas como se hacia en el pasado. Al final muchas de las aplicaciones son de coger datos, manipularlos y listarlos.

  9. Con respecto a este tema, he sido testigo de cómo gente de una famosa consultora X, nos enseñaban orgullosos una aplicación aberrante, que les había contratado una gran empresa española (no sobra decir que seguro que ha costado un dineral).

    Esta aplicación había sido creada por un equipo de gente con perfiles muy distintos al informático, con una herramienta que permite hacer aplicaciones simplemente arrastrando distintos componentes. Y la llamo aplicación aberrante no por haber sido hecha de esa forma, sino porque con todo el dinero que se han gastado, a simple vista su usabilidad era NULA: fondo rojo con letras negras, menús de color verde fosforito, la información presentada de forma muy desorganizada, letra minúscula, gráficos horribles…entre otras cosas. Se suponía que era para tablets, pero estaba estructurada para PC. Un horror y esto solo de cara al usuario. No quiero imaginarme temas de rendimiento y cosas así.

    Ante esto, les preguntamos si de verdad estaban contentos con ella, a lo que dijeron: bueno, “es que el cliente no dice nada…” “Pero veis, no os asustéis si cualquiera puede “programar” “. ¿Y la usabilidad, calidad, seguridad…? “¿Eh?(no tenían ni idea de que les estábamos hablando) Al cliente le vale así”.

    Por eso, me creo que pueda darse el caso de que aumente el número de gente que “desarrolle” aplicaciones sin saber nada, para clientes que no exijan demasiado.

    A la hora de hacer un software, hay muchos más aspectos que hay que tener en cuenta además de programar. Pero tristemente creo, que si a alguien que no sabe nada de software, le venden que hay herramientas con las que cualquiera puede crearse sus programas y una aplicación hecha de esa forma va a costar X, mientras que encargándola a alguien con más conocimiento va a costar el doble…va a optar por lo primero, con las consecuencias que conlleva.

    Me entristece mucho esa forma de pensar, porque por ejemplo, aunque no sé nada de construcción, a mí no se me ocurriría contratar a un informático para diseñar un edificio. Sé que sí que podría ser capaz de poner ladrillos, pero no hacer un plano y tener en cuenta todos los aspectos que conlleva esa construcción.

    Sin embargo, entre gente que no sabe nada de informática, está muy extendida la creencia de que informática solo es programar. Y si hay una herramienta que cualquiera puede usar y con la que puedes hacer programas, ¿para qué sirve un informático?.Y esto es una auténtica aberración!

    Miedo me da las monstruosidades que pueden salir de esta forma de pensar, de malinterpretar la utilidad de este tipo herramientas.

  10. Coincido contigo Ana María: todas la herramientas proporcionan oportunidades y presentan peligros: se pueden usar bien o se pueden usar mal. Has dado en el clavo, no es la herramienta, es el uso que se hace de ella y lo que esperamos de ella (gestión de expectativas).

    Pero a pesar de esos mal-usos (que los hay), no por ello el progreso se detiene, también hay casos de buen-uso, afortunadamente.
    Seguiremos disponiendo de mejores herramientas cada día y (opino) que seguiremos viendo como se incrementa el nivel de abstracción con el que trabajamos (para no repetirnos, para no reinventar la rueda una y otra vez).

    Es parte del trabajo de ingenieros competentes el saber elegir las herramientas más adecuadas a cada problema. ‘No Silver Bullet’.

    • El problema de la abstracción, es que se corre el peligro de pasar de tener código reutilizable a tener código no utilizable. Quiero decir que para conseguir buenos resultados hay que tener conocimientos de lo especifico. Si no que alguien me explique como se puede soportar un alto nivel de concurrencia con algo que se programa solo. Es que no nos damos cuenta de que es una locura?¿ Si el software abarca mucho aprieta poco, y un negocio es algo muy serio. Aunque haya que gastar dinero hace falta software especifico y funcional que se adapte al negocio, y no adaptar el negocio al software.
      Ayer estaba escribiendo una acción en un sistema con una arquitectura mvc, y para abstraer parte del código utilizaba un típico patrón DAO. Entonces pensé… “justo en esta acción mi aplicación ganaría rendimiento dejando a un lado la modularidad y aprovechando el contexto del api de persistencia”. Sacrifique rendimiento por tener un código as limpio y ordenado…
      Pero quizás la próxima vez me tenga que plantear de otra manera el problema. Depende de las necesidades del proyecto.

      Y lo mas importante de todo, es que los negocios crecen y cambian, y hay que tener un software preparado para eso. Quieres usar un CMS?¿ Ok, pero cuando toque crecer tendrás que pagarlo con creces. Cuando necesites escalabilidad ya ni hablemos….
      Hay grandes empresas que adaptan ese tipo de soluciones a sus necesidades?¿
      Si, pero pueden pagarlo (y es mucho mas caro que hacerlo de cero).

      Y otro problema muy español. La falta de cordinación. Una empresa productiva es una empresa afinada, organizada y bien estructurada. Si tu software no se entiende entre si, si no está perfectamente sincronizado y sabe entenderse y escucharse a si mismo…
      Bueno, eso tambien lo pagarás

    • El problema de la abstracción, es que se corre el peligro de pasar de tener código reutilizable a tener código no utilizable. Quiero decir que para conseguir buenos resultados hay que tener conocimientos de lo especifico. Si no que alguien me explique como se puede soportar un alto nivel de concurrencia con algo que se programa solo. Es que no nos damos cuenta de que es una locura?¿ Si el software abarca mucho aprieta poco, y un negocio es algo muy serio. Aunque haya que gastar dinero hace falta software especifico y funcional que se adapte al negocio, y no adaptar el negocio al software.
      Ayer estaba escribiendo una acción en un sistema con una arquitectura mvc, y para abstraer parte del código utilizaba un típico patrón DAO. Entonces pensé… “justo en esta acción mi aplicación ganaría rendimiento dejando a un lado la modularidad y aprovechando el contexto del api de persistencia”. Sacrifique rendimiento por tener un código mas limpio y ordenado…
      Otra opción seria seguir manteniendo modularidad, pero multiplicar el numero de funciones (que hacen lo mismo de diferente manera en función de lo que es mejor en ese momento), hasta tener librerías completamente inutilizables por su tamaño y complejidad.

      Quizás la próxima vez me tenga que plantear de otra manera el problema. Depende de las necesidades del proyecto.

      Y lo mas importante de todo, es que los negocios crecen y cambian, y hay que tener un software preparado para eso. Quieres usar un CMS?¿ Ok, pero cuando toque crecer tendrás que pagarlo con creces. Cuando necesites escalabilidad ya ni hablemos….
      Hay grandes empresas que adaptan ese tipo de soluciones a sus necesidades?¿
      Si, pero pueden pagarlo (y es mucho mas caro que hacerlo de cero).

      Y otro problema muy español. La falta de cordinación. Una empresa productiva es una empresa afinada, organizada y bien estructurada. Si tu software no se entiende entre si, si no está perfectamente sincronizado y sabe entenderse y escucharse a si mismo…
      Bueno, eso tambien lo pagarás

    • si la herramienta cerebro no te funciona, no adelanta buscar otro tipo de herramienta para dar en el clavo, el software es algo dinámico, cambia todo los días, porque el programador es un inventor por naturaleza y si fuera verdad lo que dice en el articulo y lo que afirmas tu, porque razón se esta enseñando a programar hasta los niños de la primaria.

  11. jamas desaparecera la programacion, es mentira que es cada vez mas facil. Es cada vez mas complejo y las herramientas de desarrollo vienen cada vez mas amplias. Lo que no ven es que el programador es alguien que toma decisiones constantemente, jamas dejen una aplicacion en manos de un inexperto porque el fracaso esta garantizado, esa aplicacion no tendra futuro alguno.

  12. el dia que haya poca dependencia a la programacion va a ser cuando hayamos retrocido 1 siglo atras y volvamos al lapiz y papel. Cada vez la sociedad exige mas y mas, y solo pueden garantizar el exito los “profesionales”, las demandas son constantes y de todo tipo. Se necesita gente con mucho conocimiento y mucha experiencia, los sistemas son “muy fragiles” ya que se rompen de la nada. Esta comprobado que cualquier aplicacion del momento que no tiene soporte camina a su fin rapidamente, pierde competencia y se rompera al primer cambio en el ambiente ya sea tecnologico o humano.

  13. no creo que no se necesiten mas programadores, ya que son estos los que crean las aplicaciones que facilitan su oficio y cada día mas y mas jóvenes estudian la carrera con herramientas que tocan muy poco esto, asi que siempre serán útiles los programadores que estén actualizados en programación a bajo y intermedio nivel y puedan ofrecer aplicaciones con un mejor rendimiento y acabado personalizado que un joven con aplicaciones que son rápidas de hacer pero dejan mucho que desear en todo lo demás, las bases de la programación es lo que nos garantiza trabajo en cualquier lugar de nuestra carrera, y leandro tiene razón la programación para móviles es lo que actualmente vale la pena saber.

  14. Lo que yo creo que se van a necesitar son programadores que aporten valor añadido a lo que programan. Yo soy ingeniero de minas, hice varios cursos de java (uno del paro, otro ya dentro de la empresa) y estoy desarrollando aplicaciones para hidrogeologia, oil and gas, y en nada me van a dar formacion para desarrollo de GIS y BidData para juntarlo con lo anterior.

    El programador/analista sin mas tiene el defecto, bajo mi punto de vista, es que “solo” (y no es poco) programa y a lo sumo analiza el problema para que otros lo programen pero ¿Sabe interpretar los resultado? ¿Y si ademas de programar/desarrollar el software es capaz de trabajar con el?

    No es raro que en simulacion numerica haya desarrolladores que no son “informaticos”, no es raro que los desarrolladores GIS no sean informaticos… y ademas, si un desarrollador informatico tiene al lado a un desarrollador no informatico pero especialista en lo que desarrollan la mezcla es brutal.

    Se que os jode, pero la inforamtica es un area en donde puede acceder mucha gente. Y el desarrollo de software algo que cualquier fisico, uimico, ingeniero que sepa (y digo que sepa) lo que hace puede puede desarrollar.

    Si hablamos de ingenieria del software, plazs, tiempo, rendimientos… pues ahi si, lo que se necesita es un ingeniero informatico.. casi la unica parecela propia de los Iinformaticos es precisamente esa, porque desarrollar aportando valor añadido casi cualquiera que aparte de ser experto programador sea experto en otra mteria y se dedique a desarrollar en su area de especialidad. En mi caso, simulacion numerica y en breve gis y BD.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This