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.

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.