La extinción de los programadores

¿Estás estudiando Informática para cumplir tu sueño de ganarte la vida gracias a tus habilidades escribiendo código? Pues siento ser yo el que te dé la noticia, pero llegas tarde.  Todavía quedan algunos programadores sueltos pero más temprano que tarde se habrán extinguido. ¿Todos? ¡No! siempre quedarán algunos irreductibles, dedicados a tareas tan específicas que no es  rentable sustituirlos por “algo” más productivo. Lo sé, utilizar Astérix como comparativa es un recurso fácil pero como lo tengo al lado, geográficamente hablando, me permito usarlo.

Te estarás preguntando, y ¿ahora qué hago? ¿me pongo a estudiar humanidades? Espera, tranquilo, tampoco hace falta ser tan drástico. De hecho, la extinción de los programadores, entendiendo “programador” como aquél que programa (dad las gracias a la RAE por esta definición tan brillante) es decir aquél que escribe el código o secuencia de instrucciones que lo componen, no es una mala noticia.

En lugar de ser programador, ahora puedes aspirar a ser desarrollador… que encima ¡cobran más! Para ser precisos, la palabra “desarrollador” no aparece en el diccionario de la RAE pero Google dice que hay casi 6 millones de entradas para este término con lo que ¿a quién vas a creer?. Tal y como lo entiendo yo (y más o menos lo que también viene a decir la Wikipedia) un desarrollador es una persona que produce software, no necesariamente programándolo o como mínimo no programando él mismo en su totalidad. En su origen, desarrollador y programador eran sinónimos pero cada vez más podemos desarrollar software sin tener que “ensuciarnos” las manos (en un sentido metafórico, sigue leyendo, ya tendrás tiempo de acordarte de mi familia en los comentarios al final, un poco más de paciencia) programándolo.

Veamos, pues, cuáles son mis tres razones para afirmar que podemos, cada vez más, prescindir de los programadores:

1.     Hay una API para ti

Para todo lo que quieras en la vida, hay una API que alguien ya ha escrito y que hace exactamente lo que necesitas… no siempre gratis, claro, pero hay una licencia tipo Creative Commons para APIs llamada API commons.  Por ejemplo, una sola web, Programmable web, tiene clasificadas más de 10.000 para todos los dominios imaginables.  ¿Quieres hacer una aplicación relacionada con temas de comida? Ahí encontrarás APIs para saber los componentes nutricionales de cada alimento,  recetas para combinarlos y restaurantes donde comerlos, por poner sólo algunos ejemplos.

Como espero que no sufras del síndrome no-inventado-aquí , antes de escribir una sola línea de código busca la/s APIs que te proporcionen los datos que necesitas y limítate a combinarlas. Para las APIs más comunes tienes incluso servicios como IFTTT que hacen el trabajo por ti. Sí, a lo mejor esto ya lo has oído antes (el boom de los componentes?  los servicios web?) pero nunca a esta escala y con una facilidad de reutilización tan elevada.

IFTTT ofrece miles de “recetas” (combinaciones de servicios en su terminología) como la del ejemplo que permite guardar automáticamente nuevas fotos tuyas en Instagram en tu carpeta DropBox

IFTTT ofrece miles de “recetas” (combinaciones de servicios en su terminología) como la del ejemplo que permite guardar automáticamente nuevas fotos tuyas en Instagram en tu carpeta DropBox

2.     Convierte un framework en tu esclavo

La última vez que escribí una aplicación web (para un familiar, no hace falta decir que hacerlo fue una muy mala idea) ni me planteé escribirlo todo de cero. Dediqué más tiempo a buscar el framework más productivo (me decanté por Spring Roo, pero ojo que ya partía del prerrequisito de que el lenguaje fuera  Java) que a utilizarlo para escribir la aplicación en sí.

Una vez tuve Roo instalado en mi Eclipse IDE y ligado a una cuenta gratuita de CloudBees para el despliegue automático de la aplicación desde mi entorno local me bastó con utilizar la consola de Roo para crear el modelo de datos de la aplicación (muy parecido a crear un diagrama de clases UML pero textual, y de hecho, se podría escribir muy fácilmente un generador UML ->Roo, pero el tema del porqué deberías modelar más lo dejamos para otro día, no hace falta provocar más de la cuenta) y dejar que Roo hiciera todo el trabajo, desde crear las tablas correspondientes en la base de datos hasta crear la interfaz gráfica por mí con toda la funcionalidad básica necesaria (patrón CRUD: create/read/update/delete). ¿Qué tú la harías más bonita? Puede que sí, y eres libre de modificar cualquier parte del código generado por Roo (y además Roo va a respetar tus cambios en el futuro), pero para la gran mayoría las opciones por defecto de Roo nos permiten  llegar muuuuuy lejos (por si a alguien le interesa hace unos años hicimos un estudio que adaptado a este contexto vendría a decir que lo que Roo genera cubre un 80% o más de toda la funcionalidad que necesita una aplicación).

Ejemplo de UI creada por ROO. Para cada campo de la clase se crea un control del tipo adecuado (y con las verificaciones necesarias)

Ejemplo de UI creada por ROO. Para cada campo de la clase se crea un control del tipo adecuado (y con las verificaciones necesarias)

 3.     Más fácil todavía. Hazlo todo con WordPress

Ya hace mucho tiempo que WordPress (pon aquí tu CMS preferido, da igual) dejó de ser una herramienta para escribir tu blog y se convirtió en un framework muy potente que permite a cualquier usuario (incluso sin conocimientos reales de programación) crear muchos tipos de aplicaciones web comunes simplemente instalando los plugins de WordPress adecuados.

¿Control de usuarios? ¿Autenticación con Google, Facebook o Twitter? ¿Carrito de la compra? ¿Web multilingüe? ¿Logs de errores? ¿Sistema avanzado de plantillas? ¿Integración con Google Maps o cualquier otro servicio de Google? Todo a un click de distancia:  el que te lleva al repositorio de plugins de WordPress.

Cierto,  no vas a poder construir el software de control para el nuevo modelo de Airbus con WordPress ni tampoco simplemente conectando un par de APIs públicas ni Roo va a ser nunca capaz de generar un software certificado automáticamente. Y por eso digo que siempre habrá algún programador que va a sobrevivir a la extinción masiva. ¿Pero cuántos modelos de  Airbus se crean cada año? (la respuesta es que el número tiende a cero). ¿Y en comparación, cuantas aplicaciones web para la visualización y entrada de datos (de facturación, proyectos, clientes,…) se crean cada día y se podrían desarrollar sin casi escribir una sola línea de código?

Los programadores han hecho un gran trabajo. Dejemos que se extingan en paz y aprovechemos la gran herencia que nos han dejado para ser mucho más productivos y dedicarnos a la parte más creativa del desarrollo de software en lugar de reeescribir código ya escrito millones de veces anteriormente.

Jordi Cabot es profesor titular en la École des Mines de Nantes (Francia) donde dirige el equipo de investigación en Ingeniería del Software AtlanMod adscrito a INRIA.  Es además cofundador de la empresa Nelio Software S.L., especializada en ofrecer servicios relacionados con el mundo WordPress.

CC BY-NC-SA 4.0 La extinción de los programadores por Comunidad UOC está licenciado bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

13 Comments

  1. Puedo entender el post si me lo tomo como una provocación al estilo Salvador Sostres, pero no de otra forma. No entiendo muy bien la distinción entre desarrollador y programador que se hace aquí, y la supuesta inflexión de la tecnología que hace que precisamente ahora programar “sea obsoleto”. Hace ya mucho tiempo que no se programa directamente con ceros y unos y los frameworks y los APIs no son nada que haya surgido ahora, de repente.

    La idea del post la he visto ya en algunos alumnos de la universidad, y me parece peligrosa (y equivocada): que programar como siempre se ha hecho es obsoleto y que ellos van a hacer unas apps de la muerte pulsando cuatro botones que combinen cosas ya hechas. Y sí, efectivamente, no tiene sentido implementarse uno mismo los árboles binarios, ni dibujar las líneas a bajo nivel con Bresenham. Pero es que programación no es solo hacer bucles y condicionales. Implica conceptos como modularidad, encapsulamiento, niveles de abstracción, estructuras de datos… que un buen informático debe dominar sí o sí, independientemente de los fantásticos frameworks o APIs que use. No comparto la idea de menospreciar la programación o considerarla como “algo superado”.

    En fin, siento que el tono de los párrafos anteriores sea quizás un poco vehemente, pero al menos no me he acordado de la familia de nadie (en contra de lo que sugería el propio post :) )

    Reply
    • Evidentemente el post está escrito en tono provocativo o sea que encantado con el tono vehemente de tus párrafos.

      Déjame contestarte dos aspectos:

      – Dices: ” y los frameworks y los APIs no son nada que haya surgido ahora, de repente.” Cierto pero en mi opinión cada vez són más importantes y, además (crítica implícita a los docentes de universidad como yo) parece que la gran mayoría de planes de estudio todavía no se han enterado. ¿Cuántos planes de estudio hay que incluyan (con algún ejercicio práctico) temas como la integración de aplicaciones o el desarrollo con frameworks de programación web? Pues la verdad casi ninguno. Para muchas universidades el tiempo se paró con la aparición de Java (y aún gracias). Yo aprendí a programar en C y C++ “a pelo” y cuando salí de la universidad y vi el Delphi (lo moderno en esos tiempos aluciné de qué nadie me hubiera ni mencionado el concepto de RAD durante mis años de carrera (la universidad no está para enseñar los lenguajes de “moda” pero sí para como mínimo mostrar un panorama de las tendencias actuales).

      – También dices: “idea equivocada ….. van a hacer unas apps de la muerte pulsando cuatro botones que combinen cosas ya hechas.” Aquí discrepamos. Con el uso de generadores de código a partir de modelos y el apoyo de APIs existentes creo que se pueden llegar a hacer cosas muy potentes sin programar más que un poco de “glue code”. Evidentemente siempre dentro de un dominio específico (en este caso, aplicaciones destinadas a la gestión de datos). Si como “apps de muerte” te refieres a aplicaciones super eficientes o con una interfaz gráfica revolucionaria tienes razón pero aplicaciones de nivel comercial en las que hasta no hace mucho se debería haber invertido bastantes horas de programción, mi respuesta es sí.

      Reply
      • Estoy de acuerdo con (casi) todo lo que me respondes (siempre tiene que haber un casi). Lo que me mata es la manía de identificar la palabra “programador” con algo de “nivel inferior”. Y “programar” con “picar piedra”. “No, no, perdona, yo soy desarrollador, no programador”. O “¿Programador? disculpa, querrás decir Ingeniero del Software”. Y precisamente esta identificación que tú haces (y que supongo introduces para dar un tono provocativo) es la que creo que motiva que algunos planes de estudio estén alejados de la realidad. Esa idea de “Hijo mío, tú no te tendrás que manchar las manos con código, como yo, porque tú vas a ser Arquitecto de Software”. Todo acompañado de una música emotiva y seguido de unas imágenes del hijo -al que vemos ya de mayor- desarrollando una app -ahora sí- de la muerte haciendo gestos al estilo “minority report” y sin picar ni una línea de código como tenía que hacer su pobre padre (perdón, estas horas de la noche es lo que tienen :) )

        Estoy totalmente de acuerdo con lo que dices en el último párrafo del post: “dedicarnos a la parte más creativa del desarrollo de software en lugar de reeescribir código ya escrito”. No creo que nadie esté en contra de eso. Se viene haciendo desde los inicios de la informática. Pero creo que escribir buen código puede ser una actividad tan creativa como modelar o diseñar. No deberíamos menospreciarlo.

        Reply
  2. Todo desarrollo de software ha sido siempre muy sencillo y el 95% de todo se resuelve muy rápido. El 5% es pelearse con APIs que no van, lidiar con que Roo o WordPress se quedan un pelín corto en un tema y tienes que meterte dentro de sus complicadas tripas para resolverlo… y ese 5% es el que hace que los proyectos no cumplan tiempos porque siempre pensamos que la API/Roo/Wordpress son la bala de plata que nos quitará toda complicación.

    O sea, sí, Brooks hace unas décadas ya decía esto.

    Reply
  3. Por cierto, soy un poco obsesivo sobre frameworks de CRUD ( http://alex.corcoles.net/2014/01/por-que-el-crud-es-importante/ ) y puedo decir que el admin de Django le da mil patadas a Roo, pero que aún le falta muchíiiiisimo.

    Creo que lo único que evita que tengas que escribir una aplicación es que alguien ya la haya escrito antes. Sospecho que el CRUD definitivo no se escribirá nunca…

    Reply
  4. Per explicar realment millor la teua proposta ho diria de la següent forma;
    un programador = un picacodis

    Un picacodi es aquell qui te un cap que li paga vora entre 6-8 €/hora, si menys que limpiar escales per implementar funcions de les que qüasi mai vorà el codi final, es a dir, es com estar a una fàbrica i montar palets. Un desenvolupador va mes enllà es un tio que independentment dels mitjants resol el problema.

    Reply
  5. Uno de los mejores post que he leido desde hace tiempo. Incluidas las respuestas.
    Para los que somos estudiantes ( aunque ya maduritos como en mi caso…y profesionales de otros sectores en nada relacionados con la programación)……este post nos plantea la eterna duda de si vale la pena tanto sacrificio en la carrera ( Informàtica en la UOC)…..o si vamos a acabar aprendiendo mas en algún cursillo de WordPress o del framework de turno. Te hace plantearte si vale la pena matricularte de esa asignatura tan complicada pero en la que te motiva aprender…o matricularte de las mas facilitas, sacarte el título sin aprender nada….y ya aprenderás por otro lado….porque lo que te van a enseñar en la universidad de nada sirve con la realidad.

    Reply
    • Antes que nada, gracias por el cumplido.

      Y en relación a lo que comentas, la verdad es que es un tema a discutir durante horas pero intentaré ser breve:

      – Durante la carrera deberías aprender los conceptos que vas a utilizar el dia de mañana. Es importante saber qué es un bucle. NO es importante saber si ese bucle se escribe con punto y coma o dos puntos en un lenguaje concreto. Lo primero es difícil de aprender, lo segundo muy fácil. Es como el saber diseñar / modelar un programa. Lo importante no es que las clases se dibujen con cajitas (en UML) sinó aprender qué cajitas hay que poner.

      – La carrera tiene que evolucionar para introducir nuevos conceptos que a lo mejor antes no eran necesarios. Saber qué es un grafo y cuáles son los algorimos de grafos está bien. Tener que aprender las veinte variantes para programar cada algorismo NO. Un ejemplo es lo que comentas de WordPress. En la carrera debería verse en alguna asignatura el concepto de CMS, como funcionan (incluso internamente), como la gente los usa, y qué modelos de negocio hay detrás. Estos conocimientos los puedes aplicar después a cualquier framework concreto como WP con un poco de aprendizaje.

      Resumiendo, la carrera y los cursos específicos en un mundo ideal deberían ser complementarios. La carrera debería darte las “herramientas mentales” para después ser capaz de aprender rápidamente lenguajes/frameworks concretos haciendo un mapping de cómo lo que ya sabes se traduce en ese lenguaje concreto.

      Reply
  6. ¿ Cual considerais que es la formación extra-universitaria que precisa un programador/desarrollador?

    Reply
  7. El “programador” nunca desaparecerá, sólo seguirá mutando como lo ha hecho hasta ahora.

    Reply
  8. Fantástico artículo, me ha gustado mucho.

    Llevo un par de meses usando IFTTT y es una herramienta muy buena, la suelo usar en varios de mis proyectos.

    Gracias por compartir

    Reply
  9. Francamente, la frase de que el programador va a desaparecer es algo que llevo escuchando y leyendo desde que que apareció windows. Han pasado muchos años desde entonces pero el programador continua existiendo, si es cierto que ha tomado mas significado el perfil del analista-programador dado que las herramientas actuales tienen mas alcance en el diseño de los proyectos. WordPress, el CMS mas utilizado del mundo, nunca podrá substituir a otras herramientas de desarrollo de aplicaciones. Creo que no es necesario demostrar lo que wordpress no puede hacer.

    Reply
  10. Hola. Esto puede ser válido para aplicandiocillas web, pero inaplicable al mundo de la optimización en C y C++. El simple hecho de utilizar APIS externas provoca graves transtornos a los tiempos y al uso de memoría, que oh! cosas de la vida, a algunos nos afectan enormemente aún disponiendo de los últimos equipos de ese momento. Por tanto, los programadores, los buenos programadores ( o ingenieros de software ), no van a desaparecer.

    Reply

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com Valora en Bitacoras.com: ¿Estás estudiando Informática para cumplir tu sueño de ganarte la vida gracias a tus…
  2. La extinción de los programadores | iNFo... - […]   […]
  3. Mi (provocativo) blog post sobre la extinción de los programadores | Yo y mis opiniones - […] resultado es este (provocativo) post sobre la extinción de los programadores (“as we know them”) que ya se puede…

Comentar

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

Leer entrada anterior
Un plan de sistemas “ágil”

La UOC, como otras universidades y escuelas de negocios, está haciendo su plan estratégico de sistemas de información, o acaso...

Cerrar