Tendencias en el desarrollo de software 2014

Con la llegada del fin de año, se acerca el momento de la clásica serie de predicciones para el futuro, o, en esta ocasión, más bien unos comentarios sobre las tendencias que yo observo en mi limitado entorno.

1) La Web ya no es sólo la Web del navegador, sino que ahora es un híbrido de HTML y apps. Las startups tienden bien a ignorar la web móvil, bien a estar demasidado centradas en ellas. Hay algunos casos en los que se justifica que el modelo de negocio gravite alrededor del móvil, Hailo, probablemente, ha sido una de las startups más llamativas en 2013, y está justificado. Pero en la mayoría de las ocasiones es más bien entre un 60→70% web clásica y un 30→40% móvil. La movilidad afecta no sólo a la tecnología base en si misma (que tiende hacia HTML5 y Open GL para evitar en la medida de lo posible desarrollar dos veces para iOS y Android) sino que también tiene mucho que ver con el marketing debido a que en los móviles las app stores imperan sobre la búsqueda en Google para encontrar determinados usos a la tecnología. Varios frameworks se han ido popularizando para el desarrollo multiplataforma en móviles: Corona SDK, Xamarian C#, Appcelerator Titanium, PhoneGap, MoSync o RhoMobile entre otros.

Cuotas mercado móviles 2013

2) El interés por la mayor integración de redes sociales en el negocio y en las aplicaciones va a continuar siendo muy fuerte. La moda es intentar identificar y agrupar a los consumidores por sus gustos en lugar de por su perfil sociodemográfico. Además, existen intentos de explotar la intencionalidad temporal de compra. Es decir, no sólo saber qué gustos tiene un consumidor potencial sino en qué momento preciso del tiempo pasará de ser sólo cliente potencial a estar realmente interesado en comprar algo a corto plazo. No es para nada raro que lo que más esté proliferando sean las aplicaciones de marketing para Twitter estilo SocialBro. Twitter tiene aproximadamente la mitad de usuarios registrados que Facebook, 500 millones frente a 1.100 millones, y de esos 500 millones sólo 200 están activos, sin embargo, en utilidad de promoción empresarial y de causas sociales, Twitter bien puede superar con creces a Facebook, y en seguida explicaré mis motivos para afirmar tal cosa. Facebook, en teoría, permite identificar mucho más fácilmente los gustos de la gente gracias a los Like. Esto en teoría, porque en la práctica yo tengo tendencia a hacer Like sobre cosas que no me apasionan realmente (las voto porque me las sugieren los amigos) o Like sobre cosas que son muy difícilmente monetizables, como el escote de la cantatriz de moda. Esta distorsión en los Like rebaja el grado de eficiencia publicitaria de Facebook más o menos hasta el de un medio sociodemográfico como la televisión, o incluso peor, puesto que Facebook parece ignorar mi perfil personal para ofrecerme sólo recomendaciones basadas en hipótesis erróneas sobre mis gustos. Por ahora, Facebook ignora la temporalidad y la estacionalidad, es incapaz, por ejemplo de tomar la fecha de cumpleaños de mis amigos y sus gustos para recomendarme con anticipación algo que regalarles. Además, Facebook tiene menos uso en el móvil y es una red de redes de amigos en vez de una red abierta de todos con todos, como Twitter, por consiguiente la viralidad se propaga a menor velocidad en Facebook que en Twitter. Esta por otro lado LinkedIn, con 225 millones de usuarios, que, en mi opinión, está sobrevalorada como canal de marketing. Prácticamente todos los geeks estamos en LinkedIn con un perfil bastante completo a modo de CV, pero, en mi experiencia, no es posible encontrar como usuarios registrados en LinkedIn a más del 7% del total de cualquier base de datos de clientes reales. Por último, los otros tres servicios que es imprescindible tener en cuenta en cualquier estrategia en redes sociales son YouTube, Instagram y Tumblr.

3) Hay un buen batiburro de desarrollo en torno a JavaScript debido fundamentalmente a que lo que se diseñó inicialmente como un lenguaje de scripting multiparadigma para programadores no profesionales se ha extendido a usos complejos tanto en el cliente como en el servidor. Hay decenas de frameworks: JQuery, Dojo y YUI como librerías dominantes, sistemas MVC como Angular.js o Backbone.js, e incluso reemplazamientos completos del lenguaje como CoffeScript o Dart. Además del resucitado JavaScript de lado servidor con Node.js o el políglota Vert.x.

4) Los programadores Java estan evolucionando hacia Scala. Scala corre sobre la JVM y es muy compatible e interoperable con Java. Incorpora el paradigma de programación funcional así como extensiones al modelo de objetos de Java y la librería Akka para programación concurrente con Actores. Como programador, Scala se siente en la sintaxis compacta como si fuese Python, pero en realidad es un Java con esteroides. Las principales desventajas, a mi juicio, es que el lenguaje es complejo de aprender, su sintaxis puede llegar a ser muy poco intuitiva y está claro que los que lo diseñaron no estaban pensando en los desafíos específicos que presenta el software para la web sino en solucionar otros problemas de programación funcional, orientada a objeto y concurrente.

5) Las startups de base tecnológica se implementarán mayormente sobre Python o Ruby On Rails. No sabría decir cual en mayor cantidad. Tampoco creo que entre esos dos entornos ninguno sea claramente mejor que el otro. Ya he escrito anteriormente una comparativa sobre plataformas de desarrollo web. Aquí simplemente añadiré que basar la startup en Python o RoR es perfecto siempre y cuando se tenga en cuenta que no es conveniente empeñarse en programarlo absolutamente todo en Python o RoR. Por poner un ejemplo concreto, justo actualmente estoy programando un sistema de envío de emails para un cliente que necesita enviar 850.000 mensajes cada semana los cuales difícilmente se pueden enviar y trazar eficientemente sólo con Python o RoR y una base de datos MySQL.

5) Se encuentra “Big Data” hasta en la sopa, y, en mi opinión, no es para tanto. Todas las herramientas “Big Data” Open Source son funcionalmente bastante limitadas. Hadoop, en concreto es un sistema de almacenamiento distribuido atributo-valor (HBase) con una implementación de MapReduce por encima y eso sirve sólo para algunos usos muy concretos, ni siquiera proporciona índices secundarios de serie excepto por el mecanismo de los coprocesadores que no es en absoluto trivial de manejar. Cassandra escala muy bien y permite añadir columnas dinámicamente y de forma prácticamente ilimitada a un modelo de datos pero carece de ningún tipo de funcionalidad nativa para hacer una simple ordenación de datos.

5) La memoria es el nuevo almacenamiento. Comprar una máquina con 1Tb de RAM ya no es nada descabelllado. Con tal cantidad de RAM se pueden poner muchas bases de datos directamente en memoria y usar el disco sólo como backup. Cualqier nuevo diseño de software de gestión de datos debería tener en cuenta este hecho.

6) Se ha producido un exceso de virtualización. En 2008 ya escribí sobre el middleclouding. Ahora los llaman clouds híbridos. Las áreas problemáticas con la virtualización son que: a) es demasiado fácil clonar una máquina virtual, y b) el software no tiene ningún conocimiento sobre el hardware sobre el que se ejecutará. Es muy fácil caer en una proliferación descontrolada de máquinas virtuales, y, cuando se desea optimizar al máximo el rendimiento, es necesario saber sobre qué hardware se está ejecutando la aplicación. Yo personalmente para un SGBDR sigo prefiriendo un buen array de discos SCSI montados en RAID antes que cualquier soporte virtual porque sé realmente lo que hay por debajo y por tanto el rendimiento real que se puede esperar del sistema en condiciones de máxima carga. Usar Amazon S3 para olvidarse para siempre del almacenamiento de archivos esta muy bien para aplicaciones que son el yonki de los gigas, pero si se trata de garantizar tiempos máximos de respuesta a cada transacción, mi postura es que, aún siendo mucho más caro un cloud privado estilo Stackscale o Stackops o incluso servidores dedicados, son mejores opciones que los proveedores de servidores 100% virtuales donde nada se sabe acerca de la infraestructura física que soporta el servicio.

7) Los programadores seguirán ganando poder, quizá demasiado poder. En el mundo anglosajón la tendencia es hacia substituir al gerente de cuenta por un “lead developer”. La idea es que los gerentes de cuenta son malos, porque se trata (es un suponer) de licenciados en empresariales con un master en marketing que no hacen otra cosa que liarla en los proyectos. Entonces aparece un programador iluminado y exclama: “¡Hey! Agile es la solución para que los proyectos se cumplan en plazo, funcionalidad y rendimiento”. Y, como nadie excepto el programador entiende realmente la tecnología pues todos aceptan esa nueva concepción del desarrollo programador-céntrica. La consecuencia de lo anterior es que se hacen desarrollos por el programador y para el programador en detrimento del usuario final representado por el (inexistente) gerente de cuenta. Creo que la cura para esta zona gris de Agile es una evolución de Agile hacia una filosofía más usuario-céntrica y menos código-céntrica. Algo en la línea de Dragon Dreaming que le escuché por primera vez a Ángel María y sobre la que escribiré otro post en un futuro próximo.

Post relacionado: El estado del arte del software 2012.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Computación en la Nube, Tecnologías Emergentes, ¿Dónde estamos? ¿Hacia dónde vamos?. Guarda el enlace permanente.

7 respuestas a Tendencias en el desarrollo de software 2014

  1. Pingback: Tendencias en el desarrollo de software 2014 | Blog OBICE

  2. Jaime Buelta dijo:

    Hola!

    Me resultan interesantes todos los puntos, pero sólo quería dejar un comentario acerca de Python. Si bien coincido en que no necesariamente todo en un proyecto tiene porqué usar las mismas herramientas (incluyendo el lenguaje), dado que en donde trabajo usamos Python para casi todo y mantenemos números mucho más grandes que los que comentas (usando MySQL, por cierto), bueno, creo que al final lo que es más importante decir es que lo definitorio en sistemas grades es mucho más la arquitectura que el lenguaje particular que se use. Y que, en caso de encontrarte con que tus herramientas no dan más de sí para el proyecto particular, bueno, pues siempre se puede hacer una migración a otra herramienta que sea más adecuada.

    Todo esto lo digo como Pythonista irredento, a quien oir “lenguaje de script” hace saltar las lágrimas :-P Pero en el tiempo que llevo usando Python como lenguaje principal a tiempo completo (va para 4 años ya), no me he encontrado ningún problema (y los he tenido gordos) en el que el lenguaje fuese el factor limitante. Excluyo, obviamente, ser forzado a utilizar un lenguaje particular (JavaScript para el navegador o hacer algo en sistemas antiguos en C++, por ejemplo)
    Eso no quiere decir que no los haya, pero, en mi experiencia, son mucho menos habituales de lo que se cree…

    (Por referencia, trabajo con sistemas fuertemente distribuidos dando servicio a millones de usuarios)

    • Lo que tenía en mente acerca de Python+MySQL mientras escribía el post es que las librerías estándar de programación concurrente de Python están más o menos al nivel de las primeras de Java, antes de que estuviera disponible el paquete java.util.concurrent o Akka. Además, MySQL es especialmente lento insertando filas respecto a otras bases de datos. No es que no se pueda hacer en Python, que sí se puede, mas para el desarrollo de un bulkmailer multithread con almacenes NoSQL a mi me resulta más práctico implementarlo en Java/Scala.

  3. Pingback: Enlaces de la semana | Bianka Hajdu

  4. David Clothier dijo:

    Suscribo todo lo que dice el artículo. Echo de menos un pequeño epígrafe, aunque está relacionado con el punto (3). Tiene que ver con la librería d3.js, el futuro (ya presente) de la visualización gráfica. Creo que con el big data hay un nuevo campo por explorar y cada vez más demandado, que es la visualización de gráficos e “infografías” ricas e interactivas. Los gráficos estáticos de excel han muerto (y Flash ya ni te cuento). Los programadores tenemos mucho que decir (y hacer) con librerías como la que cito.

  5. Beranrdo dijo:

    Interesante artículo, solo un comentario en cuanto a la primera línea del mismo, “se acerca el momento de la clásica serie de predicciones para el futuro”, con decir “predicciones” se sobreentiende que son para el futuro!

    Saludos,

  6. Victor Godoy dijo:

    Hola, a mi criterio todo lo dicho esta bien dicho, solo tenemos que agregar las habilidades natas del desarrollador, despues de leer esto me gustaria saber la opinion que se tiene actualmente de Lianja, sin tomar en cuenta el costo actual, ya que aquie con esta herramienta vamos a poder manipular diferentes herramientas fuertes,SQL,PHP,JAVA,PYTHON,RUBY ON RAILS,C, y otras mas, como les pareceria y que cambiarimos los desarrolladores al hacer una combinacion con estas herramientas, claro producto nuevo y necesitamos mas info. pero que tal con la info. inicial que se esta lanzando, me intriga que aqui no se mencione. Ate. Victor Godoy

Deja un comentario

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