Rafa G. Blanes Blog

Me encanta prototipar, probar conceptos, ideas y ponerlas en marcha sencillamente para validarlas o por profundizar en tecnologías que me gustan. Esto creo que es uno de los vicios de muchos desarrolladores, la necesidad sana de aprender cómo funciona tal framework, cómo desplegar con Heroku o cómo funciona el mecanismo de plugins de cualquier software, por poner algunos ejemplos.

Ahora bien, si queremos probar una idea no podemos perdernos en los detalles y desviarnos así del asunto relevante que queremos conseguir. No obstante, veo lo fácil que es perderse en esos detalles y no centrarse en lo importante realmente, lo que aporta valor al proyecto, producto o idea que estamos probando.

De ahí el conocido mantra en nuestra profesión de poner el foco completamente en la funcionalidad particular de un proyecto de modo que la general debe ser cubierta por el entorno a usar en forma de librerías reutilizables, plugins, extensiones, plantillas, etc, cualquier cosa, en definitiva, reutilizable.

Es como si se nos planteara realizar una plataforma para la gestión empresarial y decidiéramos hacerlo todo desde cero y no contar con algunos de los productos que ya existen como base en el mercado. Sería, cuanto menos, inviable en términos de tiempo y esfuerzo.

Sin embargo no siempre pensamos en adquirir alguna solución de tipo comercial ya existente y comenzar a partir de ella y, de nuevo, caemos en el error de reinvertar la rueda una y otra vez, sin evaluar realmente el coste de esto. Una cosa es investigar e implementar por simple gusto o curiosidad en tu tiempo libre y otra muy distinta justificar decisiones en tu compañía que supongan costes extra que se pueden evitar.

Vicio, mala práctica o pura ignorancia, este es uno de los déficits habituales de muchos desarrolladores que, además, es de camino inverso: no saber seleccionar componentes del mercado o de código abierto y también no saber desacoplar lo suficiente lo que se hace para reutilizarlo en un futuro.

No sólo estoy pensando en grandes productos comerciales que hay que configurar y adaptar a necesidades específicas, sino en pequeños componentes desde plugins gráficos, templates, engines de búsqueda, etc.

Hoy día existe un auténtico mercado en el que se pueden adquirir a un precio que resulta irrelevante para el esfuerzo que tendríamos que dedicar a hacer algo similar (y seguramente, no con la misma calidad por no ser tan expertos en ese tema en concreto).

Sí, para casi todo existe algo open source y de excelente calidad, por lo que también es una alternativa a considerar aunque no podemos cerrar puertas y usar algo libre (y gratuito) porque sí, cuando podemos encontrar cosas por pocos euros de mejor calidad. ¿Qué son unos cuantos euros cuando te pueden ahorrar decenas de horas de trabajo?

Recientemente hemos adquirido un tema para un landing page de un nuevo producto que hemos lanzado: necesitábamos una página de inicio muy atractiva, sencilla, con pocos contenidos y que resultara moderna, así que decidimos usar parallax que tanto se ve en los últimos dos años. Algunos buenos ejemplos de este tipo efectos aquí.

Moda o no, la realidad es que implementar una página de inicio así y que además sea responsiva tiene muchísimo trabajo y hay que ser un buen experto en HTML5 y CSS3 para realizar una buena implementación, sin hablar de los aspectos estéticos y de diseño. Además, no me quiero ni imaginar el esfuerzo de asegurar que la implementación se lleva bien con todos (o la mayoría) de navegadores y dispositivos... Imposible de asegurar a no ser que dispongas de muchísimo tiempo para probarlo.

¿Por qué centrarte en ese desarrollo (que no es el core de tu sistema) cuando puedes adquirir por poco dinero una solución profesional y ya implementada, usada por cientos de usuarios y extraordinariamente depurada? ¿No es como contratar a alguien muy bueno en su nicho por poco dinero y tenerlo a tu disposición? Muchos fracasamos en algunos proyectos por no poder vencer esa necesidad (un poco egocéntrica) de querer hacerlo todo uno mismo, no saber delegar (adquirir componentes externos es una forma de delegación) y no saber centrarnos realmente en lo importante del proyecto.

Decidimos usar un paquete desde Envato Market que nos costó.....8 dólares, cantidad de dinero que además te da la oportunidad de preguntar al mismo autor y ver multitud de ejemplos. Es decir, unos cuantos cafés por algo que al menos yo tardaría en implementar semanas y de lejos tan bien como un experto en esas técnicas.

¿No es eso una muestra de productividad? Otra cosa es personalizar el componente lo suficiente para que todos tus trabajos no parezcan iguales.

Por 8 dólares tienes a tu disposición un desarrollador que ha trabajado mucho en ese paquete que estás comprando y que precisamente por estar más especializado en esa área lo va a realizar seguramente mejor que tú. El desarrollador gana porque su componente se vende cientos o miles de veces.

El concepto de reutilización está en las entrañas y en la esencia del software, pero no siempre lo tenemos 100% presente.

A ver, es que me he encontrado con ciertas actitudes de desprecio cuando uno comenta que recurre a Bootstrap o cualquier otra cosa como si eso fuese poco profesional: lo profesional es aprovechar tus recursos (tiempo) lo más productivamente posible. La última palabra la tiene siempre el cliente, que es el que dice si le gusta o no y realmente lo no profesional es suponer un coste de un mes de trabajo a tu empresa cuando ese mes se puede reducir a unas pocas horas por invertir unos cuantos euros en un componente ya existente.

Ahora mismo existe un gran ecosistema de componentes de modo que muchos desarrolladores que trabajan en proyectos, más que desarrollar software, pasan la mayor parte de su tiempo integrando distintas piezas de software reutilizables para conseguir la funcionalidad particular que le pide el cliente, lo cual no deja de ser un aspecto interesante de nuestra profesión.

Yo no veo que esto sea malo ni muchísimo menos, sino que es una forma maravillosa de no realizar trabajo doble y además puedes participar sin ningún problema en todo ese mercado de venta de componentes y librerías ofreciendo tus propios desarrollos: plugins, themes, etc., lo cual, además, te puede dar cierto prestigio como profesional.

La pregunta de este post es algo típica pero no menos importante; recientemente leía que en un 70% de los casos de gente que abandona su empleo, en realidad están huyendo de sus jefes. Lamentable, sobre todo porque un buen profesional se puede echar a perder si no se rodea del equipo adecuado, pero, en especial, de un jefe (manager o coordinador) que haga bien su trabajo. También oí una vez decir a Sergio Fernández que uno tiene que poder elegir a su jefe. Sea así o no, la realidad es que un mal gestor puede hacerte la vida imposible y uno bueno puede hacer que vayamos a la oficina con una motivación extraordinaria.

Entre otras cosas, dirijo equipos de desarrollo desde hace mucho tiempo y llevo años con la convicción de que un buen proyecto tiene éxito no sólo por la profesionalidad con la que se encara, también por el buen hacer de quien tiene ese trabajo de coordinar el de los demás.

Nunca me ha gustado la palabra jefe, ni manager (¿pero por qué en LinkedIn todo el mundo se etiqueta como manager de algo?), por sonarme demasiado a jerarquía o como si dentro de cualquier organización unas personas fuesen más importantes que otras. Cada uno tiene su papel y para que todo funcione, cada uno, individualmente, tiene que hacer el suyo de manera profesional. Sí, esto suena muy democrático y guay decirlo, no lo es tanto aplicarlo en el día a día. Esa idea de "todo vamos en el mismo barco", "el equipo es lo primero", etc. que tanto les gusta a los managers de medio pelo repetir, no siempre se traduce en acciones reales. Vamos, que una cosa es lo que se dice y otra muy distinta lo que se hace.

Pero, ¿en qué consiste en realidad ser un buen gestor?, ¿puede un proyecto con éxito considerarse como tal si el equipo de trabajo está quemado y el gestor es el que se lleva todas las medallas ($)?, esto último es tanto como decir que las empresas y compañías existen sólo para hacer dinero y generar beneficios. No, no sólo deben existir para eso, los beneficios deben ser una consecuencia de hacer las cosas bien y proveer de un trabajo de calidad a todas las personas que forman parte de esa organización. 

En cierta forma, un proyecto software tiene una naturaleza un poco especial a diferencia de otro tipo de trabajos, de modo que hay que conocer bien esos detalles diferenciadores para que todo vaya bien. 

¿Quieres mejorar como gestor? ¿Quieres evaluar a tu jefe y a lo mejor ponerlo a caldo? Pues sigue leyendo.

A continuación indico lo puntos claves y básicos que en mi opinión hacen de un gestor un buen responsable de proyectos software:

• Conoce en todo momento lo que hacen los miembros de equipo que dirige.
• Nunca ordena sin más: planifica y organiza para que se sepa en cada momento lo que tiene que hacer cada uno y todo el mundo conoce la coherencia y el contexto de las tareas encargadas.
• Para golpes: puesto que tu jefe tiene seguramente sus propios jefes, es fundamental que actúe en ocasiones como paraguas. En otras palabras, los miembros del equipo tienen que aislarse del ruido de fondo, ansiedades o guerras internas de otras partes de la compañía. La creatividad no puede surgir en un entorno envenenado y donde la presión y el estrés se pueden palpar.
• Estimula y motiva, esto es, aplaude las mejoras y los logros y siempre realiza críticas constructivas con ánimo de mejorar. 
• No sabe lo que es un error: llama "resultado mejorable" al error o fracaso.
• Comparte conocimientos: si el gestor lo es porque cuenta con más años de experiencia y está curtido en muchas batallas profesionales, su función es trasladar ese conocimiento al equipo.
• Nunca se fija en lo personal, siempre en los resultados aportados de cada uno.
• Delega: es muy típica la desconfianza de muchos gestores que creen que como ellos nadie puede hacer esa tarea en apariencia complicada o de responsabilidad. Esto es un error, he visto infinidad de veces cómo cuando a los miembros del equipo se les da responsabilidad y sobre todo, confianza, pueden llegar a hacerlo mucho mejor que tú y, por tanto, todos salen ganando: el primero porque delega, el equipo porque así gana experiencia.
• Asume los fallos: esto puede parecer un poco heavy de decir, pero si un miembro del equipo mete la pata, y la mete hasta el fondo, el responsable es su jefe o manager. No hay más. La cara al resto de la organización la tiene que dar él. Cuántas veces gestores (que yo llamo barriobajeros,  chanchulleros o trepadores) acusan firmemente con el dedo a la gente del equipo para esquivar los golpes. Como en todo, si una persona no es honesta fuera del trabajo, ¿por qué lo va a seguir siendo dentro? Quiero decir, somos las personas que somos en todo lo que hacemos.
• Promociona los buenos resultados siempre que puede entre el equipo. Los equipos tienen el derecho de progresar, en lo económico y en lo profesional. En muchas ocasiones, el gestor es el interlocutor con el resto de la organización para hacer eso posible. Si no mejoras es que empeoras. 
• Busca equipos coherentes. En el equipo todos tienen que aportar y se tiene que respirar un buen clima de trabajo, proactivo y estimulante. No se puede transmitir al equipo tus propias ansiedades, incertidumbres e inseguridades. ¿Quién no ha tenido alguna vez un jefe alicaído, negativo, protestón y que contagia estrés a los demás? ¿Se puede promover la creatividad y la innovación en un ambiente así?
• Un jefe quizá necesite más formación que nadie, de modo que debe ser una persona que se recicla continuamente. ¿Por qué? Un gestor de equipos debe dominar ciertas habilidades no necesariamente técnicas: debe comunicar bien y eficazmente, debe organizarse de manera extraordinariamente productiva para cumplir con sus obligaciones, debe saber gestionar y motivar a las personas, entre otras cosas. Al final anoto una serie de libros que me gustan en este sentido.
• Trabajar con gente tiene a veces sus sinsabores: el gestor debe identificar cuándo un miembro del equipo no funciona y por qué, por la razón que sea, y apartarlo del mismo. En alguna ocasión he provocado que algunas personas salgan de la compañía donde he estado trabajando en ese momento (por falta de compromiso y de competencias de esas personas, claro), os aseguro que es muy duro, te quita el sueño (literalmente), pero es necesario para que el trabajo salga adelante. Irónicamente, con el tiempo los equipos involucrados me agradecieron esa actitud de firmeza.
• Un buen responable no puede nunca tener favoritismos hacia nadie, esto crea una sensación de injusticia entre la gente.
• Pero, sobre todo, un buen gestor pone los medios para que el equipo trabaje tranquilo, centrado en las tareas de cada momento y con los medios adecuados.

Seguramente este tema dé para escribir un libro entero y más de uno esté calificando del uno al diez a su propio jefe según los puntos anteriores.

Siempre lo digo y no me cansaré de repetirlo: el éxito de un proyecto software es el éxito colectivo de todos los miembros del equipo, desde el diseñador, los desarrolladores, el gestor y el empresario que ha apostado por ese proyecto.

Si quieres saber más, aquí te recomiendo muy brevemente algunos libros que leí hace tiempo y sus enlaces directos a Amazon, una selección un poco heterogénea entre académica y de desarrollo personal, porque un buen gestor debe dominar muchas facetas de su desarrollo como profesional (buen orador, comunicador eficaz, buena organización del trabajo, etc.)

Behind Closed Doors: Secrets of Great Management, magnífico libro sobre gestión.

Aprendiendo de los mejores: Tu desarrollo personal es tu destino, de Francisco Alcaide. He descubierto a este autor este verano y he leído varios libros suyos. Un buen libro de motivación para mejorar en todos los aspectos de tu vida, también el profesional.

Organízate con eficacia: Llega más lejos de lo que nunca hubieras imaginado, básico para poder afrontar una buena organización del trabajo.

Cómo hablar bien en público e influir en los hombres de negocios (Elipse), libro de cabecera para aprender a transmitir tus ideas y comunicar bien.

Avanza el verano y en breve me tomaré unas semanas de vacaciones. Es como una especie de parón en tu día a día, en el trabajo, en la rutina familiar.

¿Cómo ha ido en un sentido general esta primera parte del año? No puedo evitar hacerme preguntas de este tipo. Así que aunque no soy muy dado a compartir reflexiones introspectivas en mi web, haré un resumen de este agitado año, al menos desde el punto de vista profesional y técnico, de todas las cosas y temas con los que he tratado.

Durante esta primera parte del año hemos cerrado proyectos importantes y abiertos otros nuevos, trabajamos en la realización de un prototipo software con el que vamos a preguntarle al mercado el interés que puede haber en él y planteamos ya una revisión profunda de uno de los productos que comercializamos.

Del mismo modo he avanzado en varios proyectos personales (he registrado mi primera marca) y por fin hemos puesto la primera piedra, como se suele decir, en otro proyecto después de tres años de planos, arquitecto, licencias, etc.

Lo que me pregunto es cuánto hay de mi forma de gestionar los proyectos software que dirijo en todos esos proyectos que, digamos, se gestan fuera de mi horario laboral, y al revés. En definitiva, creo que para cualquier actividad valen los conceptos de definición de roles y en todas es mucho mejor la colaboración que la imposición. Es liberador saber que no tienes que llevar siempre la razón y que el mundo se modela a medida que haces cosas y resuelves problemas.

Lo que sí sé es que en todos esos proyectos, sean del tipo de que sean, se avanza resolviendo problemas. No hay más. Emprender en algo consiste en resolver los problemas que van surgiendo de la forma más ágil posible. En realidad, cualquier problema es algo que tienes que aprender y sólo la carga emocional negativa que le quieras dar es lo que lo convierte en un problema. En fin, que divago.

A continuación escribo sobre lo mas significativo para mí de esta primera parte del año.

Javascript y librerías relacionadas

Parece ser que estamos viviendo un gran auge de un lenguaje que tiene muchos años: puesto que se está imponiendo la web en casi todo lo que hacemos y afortunadamente vamos convergiendo hacia estándares, Javascript tenía que jugar un papel muy importante.

En mi opinión esto será aún mejor cuando se popularice la revisión del lenguaje ECMAScript 6, revisión con la que se le dota de una mayor madurez y que contiene características que los desarrolladores acostumbrados a otros entornos siempre hemos echado en falta. ES6 es como el hermano mayor de Javascript con el que irán convergiendo todos los entornos (NodeJS), liberías (AngularJS) y frameworks que usan este lenguaje.

No obstante, me sorprende que exista cierta cultura de clean code y de refactorings continuos pero por alguna razón ésta siempre se aplica a lenguajes como C# y Java y no siempre a los desarrollos de Javascript, de modo que es muy fácil encontrar código en este lenguaje por todas partes verdaderamente sucio, no hay más que husmear desde Firebug o la DevTools de Chrome con cualquier web y descubrir cosas realmente significativas y curiosas en webs que reciben miles de usuarios diarios. Hay mucho por hacer...

AngularJS

Comencé con AngularJS en 2014 y desde entonces lo he usado en todos los proyectos que he dirigido con interfaces web. 

Aunque es más apropiado para SPA (single page applications) se puede sacar provecho de esta librería en cualquier aplicación web. Sin ninguna duda, una solución intensiva en código Javascript es más rápida de escribir y si se cuida bien la organización de los assets, queda muchísimo mejor estructurada de cara a su mantenimiento y evolución.

Como todo: un buen uso de AngularJS da lugar a una solución clara, limpia y bien estructurada, un mal uso puede generar una solución realmente sucia y difícil de seguir.

Me encantan las directivas de AngularJS; recientemente estoy viendo más y más publicaciones sobre Polymer, librería para crear componentes webs que aún no conozco del todo y similar a las directivas de AngularJS.

Flujos de trabajo para casi todo

Cualquier trabajo no es sólo una cuestión de realizar una tarea concreta con un comienzo y un final, ésta tiene que estar enmarcada en un procedimiento o flujo de trabajo que ordene cómo realizar las tareas.

Del mismo modo, cualquier trabajo que se tiene que repetir y que puede ser más o menos complejo se tiene que organizar para que cuando se repita, se haga correcta y eficientemente. Esta primera parte del año me ha tocado definir flujos de trabajo en distintos contextos. Lo más relevante de esto es que veo que casi nadie se preocupa por formalizar este tipo de procedimientos para que no haya que re-pensar una y otra vez cómo hacer las mismas cosas (perdiendo un tiempo precioso en el camino).

A nivel técnico, he usado intensamente grunt para una aplicación web en la que trabajo desde hace un tiempo y he escrito varios procedimientos acerca de su despliegue ordenado, validación, etc.

Igualmente, hemos comenzado un proyecto (ajeno totalmentae al software) que consiste en la construcción de unos alojamientos rurales, después de varios años de proyecto, planos, permisos, etc. Puesto que somos varias las personas implicadas, tanto los dueños como el arquitecto, el aparejador, el constructor, etc., he definido lo mejor posible el rol de cada uno para que a cada paso que haya que dar no tengamos que hablar todos-con-todos, bloqueando la toma de decisiones del día a día y suponiendo una carga de trabajo adicional (e innecesaria). Esta es la única forma de avanzar en los distintos proyectos que tienes en tu vida profesional y personal, o eso espero, ¿?

GIT no sólo para código

Me encanta GIT, ¿a quién no? Este año he comenzado a usarlo no sólo como herramienta de control de versiones y repositorio para código, también para otro tipo de documentos como los dos libros en los que estoy ya trabajando.

Aunque existen herramientas visuales para GIT y viniendo del mundo de Microsoft, llega un momento en que aprecias la comodidad de usar la consola para muchas tareas, sencillamente termina siendo más eficiente. Escribiendo esto se me viene a la cabeza ese magnífico y clásico libro de Neal Stephenson titulado En el principio... fue la línea de comandos. Genial y de obligada relectura cada ciertos años.

Optimización y rendimiento web

Al haber trabajado muchos años en el backend, he dedicado mucho tiempo a la optimización de código (a veces por necesidad y otras por puro placer, esa es la verdad). Esta primera parte del año he profundizado muchísimo en la optimización ya no sólo de los flujos de trabajo de una aplicación web profesional, sino en la optimización de todos los assets necesarios para la navegación con el frontend: ficheros html, css, imágenes, fuentes, minificación, técnicas de caché avanzadas, análisis en profundidad de los requests que realiza el navegador, buen uso de los selectores css, he aprendido que hay frameworks para el layout más eficientes que otros, el overhead que puede suponer obsesionarte por que tu aplicación sea responsiva, retraso intencionado en la carga de recursos y un larguíiiisimo etcétera.

Curiosamente apenas hay literatura en español sobre este tema tan importante, dado que el mundo web está creciendo exponencialmente y pocos desarrolladores conocen al menos las técnicas más relevantes. 

La clave está en ejecutar todas estas técnicas de optimización sin ofuscar la solución.

Sobre desarrollo web he mantenido muchas conversaciones interesantes acerca de lo poliédrico que puede ser el desarrollo de un portal web: además de la elección de las tecnologías correctas, no se pueden obviar las técnicas de optimización, tampoco ignorar estrategias SEO / SEM, integrar analítica web, etc. De modo que cuando leo un currículum en donde se pone "desarrollador web", la verdad es que no sé qué pensar...

Nginx y Redis

Para el proyecto que estoy a punto de publicar he usado por primera vez Nginx y Redis, dos proyectos que me parecen fantásticos. Nginx juega un papel muy importante para la arquitectura de despliegue para un sistema muy escalable (muchos usuarios concurrentes accediendo a un portal web) al tiempo que con Redis se puede jugar muchísimo para conseguir enormes mejoras de rendimiento en distinto tipos de aplicaciones.

Visual Studio 2015

Hemos comenzado a usar Visual Studio 2015 estos meses atrás y adentrarnos de lleno con ASP.NET 5 y NDX, la nueva revisión del Entity Framework, etc. Sorprende cómo se han ido adoptando las formas de trabajar con proyectos open-source en este nuevo tipo de proyectos con Visual Studio 2015 y esta nueva revisión de ASP.NET.

Desarrollo para la nube

Uno de los aspectos que siempre me han gustado más sobre el desarrollo de software ha sido optimizar y mejorar el rendimiento, sobre todo de aquellas partes de un proyecto que pertenecen más al core y de lo que depende todo lo demás.

Con el desarrollo masivo de aplicaciones web y teniendo en cuenta que la economía se está moviendo a lo digital, trabajar en el buen rendimiento de un sistema puede suponer una gran ventaja competitiva y generar mejores resultados económicos.

Por alguna razón siempre he visto cómo todo lo relacionado con el perfomance sólo nos ha preocupado como desarrolladores cuando esto suponía un error en el sistema, de modo que si algo funcionaba (aun con una latencia de algunos segundillos) pues a casi nadie le importaba. Ahora no, ahora hay que arañar hasta el último milisegundo y por supuesto ganamos la batalla si la percepción del usuario final es la de que algo va a golpe de clic. También he visto cómo se ha intentado solucionar problemas graves de rendimiento con más hardware...

El rendimiento de un sistema no consiste sólo en que funcione con la velocidad adecuada, sino también en que el usuario que lo usa perciba que responde ágilmente y de manera instantánea.

Lo que defiendo en este post, sobre todo en desarrollo web, es que trabajar con el rendimiento en mente se debe hacer desde el principio hasta el final del proyecto.

No hace mucho leí que un usuario percibe algo como instantáneo si obtiene una respuesta en menos de 100ms, entre 100 y 300ms percibe un ligero retraso, entre los 300ms y el segundo ya nota un retraso apreciable, después de un segundo se produce lo que se llama un cambio mental de contexto (mental context switch, o sea, que empieza a pensar en otra cosa) y a partir de los diez segundos (!!#***xxxx)  ha abandonado lo que intentaba hacer... En estos dos últimos casos las posibilidades de que abandone la web son muy altas. Una web lenta echa a los visitantes como moscas en una fábrica de insecticida.

Esto tiene un impacto brutal en webs en donde una tasa de rebote alta significa menos usuarios y por tanto menos posibilidades de materializar algún tipo de resultado en el site (en forma de nuevas inscripciones, ventas, descargas, etc.). Por tanto, trabajar en mejorar el rendimiento no es que sea algo secundario, sino que sin él todo lo demás que hagamos seguramente no tenga tan buen resultado como esperábamos.

Tradicionalmente los equipos de desarrollo se han preocupado del rendimiento de lo que hace al final del proyecto, cuando ya se da casi por cerrado y cuando posiblemente apenas se tenga ya tiempo parar mejorarlo y todo el esfuerzo pendiente se deba dedicar a detectar y corregir errores de validación. Esto es un error en el que yo he caído mil y una veces..., no obstante, como se suele decir, nada mejor que señalar los errores ajenos cuando uno mismo ya los ha cometido previamente, de modo que más que considerarme presuntuosamente experto, tendría que decir que la experiencia me ha dado muchas (y dolorosas) lecciones.

Desde el primer momento en que se comienzan a generar assets en el proyecto, del tipo que sea, hay que comenzar a trabajar desde el punto de vista de su rendimiento; en otras palabras, tenemos que integrar en el día a día el mejorar esos assets como una parte más del trabajo, sobre todo si el éxito o fracaso del proyecto dependen de la buena o mala percepción de los usuarios en cuanto a usabilidad y tiempos de respuesta del sistema. Me pregunto, ¿pero es que existe algún sistema software que se pueda permitir que un usuario esté varios segundos esperando para hacer cualquier cosa trivial? Claro, los hay, y muchos, me temo, y seguramente esos productos estén en la línea roja con posibilidad de ser sustituidos por la competencia.

El trabajar desde el principio en mejorar el rendimiento no es inocuo ya que de alguna manera, escribir con la optimización en mente implica:

• Crear estructuras de código optimizadas en donde ahorrar tan sólo unos cuantos ciclos de CPU es importante. Es difícil a veces encontrar el equilibro para seguir manteniendo código legible sin ofuscarlo al optimizarlo.
• Trabajar con el rendimiento en mente impacta también en el diseño del sistema: no sirve de nada plantear una arquitectura de la información fantástica si detrás no está respaldada con saltos ágiles y rápidos cuando un usuario navega por una web.

El mejorar el rendimiento implica a todos lo que trabajan en el proyecto: desarrolladores, diseñadores, arquitectos de información, etc.

El rendimiento no es sólo que un trozo de código funcione lo más rápido posible, es un concepto poliédrico, con muchas caras, sobre todo en una aplicación web donde hay muchísimos elementos involucrados:

• Conseguir un buen performance depende de la infraestructura software que usemos (servidores HTTP intermedios, SSL, etc.)
• Hay que establecer una buena estrategia de caché para los distintos elementos de la web.
• Hay que analizar si es conveniente o no usar CDNs.
• Hay que validar y optimizar (minificando y contatenando) los ficheros CSS y js. Sí, los estilos se pueden optimizar para que el navegador tarde menos en procesarlos y renderizar los resultados.
• Si se hace un uso intensivo de imágenes, estas deberían estar optimizadas y habría que ver en qué casos se podría emplear la técnica de uso de sprites.
• No hablemos ya si plateamos una web con estrategias de RWD o RESS, ahí se complica un poco más las optimizaciones según el dispositivo del usuario.
• Hay que tener mucho cuidado de las librerías externas o de terceros a usar y detectar cuales de ellas pueden constituir un SPOF y dejar K.O. el site.
• Lo que entendamos por buen o mal rendimiento depende del tipo de proyecto.

No podemos dejar todo ese trabajo de auditoría y análisis de rendimiento (de calidad, en definitiva) para el final, sino que hay integrar esas tareas en el workflow habitual de trabajo o en los procesos de entregas o integración continuas si se tienen establecidas.

Lo más importante de todo (y quizá lo más difícil): el trabajo sobre el rendimiento de algún aspecto concreto se debe poder medir de manera automática para poder ver el progreso o retroceso a medida que avanza el proyecto.

Estamos comenzando un nuevo proyecto para el mercado eléctrico, en esta ocasión 100% web (con un backend que extrae información de un enorme repositorio de información alojada en cloud); estamos integrando en el primer prototipo todas las métricas de rendimiento que nos permita analizarlas a medida que el proyecto avance en los próximos meses además de integrar en el flujo de trabajo habitual la generación automática de todos los assets optimizados. Espero así que este trabajo, que al principio parece extra, consiga que los usuarios finales del site perciban un sistema ágil y por tanto consigamos generar una percepción positiva del mismo.

Me gusta Etsy, no sólo porque implementa en la realidad una economía colaborativa hacia la que, en mi opinión, todo debería converger, también porque cuenta con un equipo de desarrollo supermotivado que además publican sus insights. En su blog hablan mucho de rendimiento web.

Me atrajo NodeJS desde un principio, cuando oí eso de código de servidor escrito en javascript. Después de aprender las nociones básicas hace un par de años, integrarlo con multitud de módulos y estar a punto de terminar un proyecto completo con este framework, en el que he estado trabajando en el último año, puedo decir que aún viendo sus pros pero también sus contras, sigue siendo para mí una maravillosa plataforma sobre la que construir aplicaciones escalables y mantenibles.

Framework, plataforma, tecnología... se mezclan un poco los conceptos: NodeJS te ofrece el core o framework esencial sobre el que construir aplicaciones, junto con un modelo de programación basado en eventos y una serie de módulos básicos pero muy importantes.

Lo que le da vida realmente a un proyecto con NodeJS es el enorme y vasto ecosistema de módulos que existe a su alrededor, que fueron apareciendo desde el primer momento en que NodeJS salió a escena y que hoy día siguen creciendo y evolucionando.

Esto es algo típico y la tendencia natural en software, como Drupal, Wordpress o el recién salido del horno ASP.NET 5 como framework de aplicaciiones web, sin cuya constelación de módulos que extienden o mejoran su funcionalidad no serían lo que son hoy en día.

Pero no es sólo cuestión de elegir e integrar un conjunto de módulos: es necesario utilizar un grupo de herramientas para una correcta gestión de la configuración de tu proyecto y para la puesta en marcha de los flujos de trabajo que hayas definido, además de aplicar continuamente buenos principios de desarrollo, clean code y una refactorización siempre presentes.

En este proyecto web con un backend bastante pesado en el que llevo trabajando un año he tenido oportunidad de usar NodeJS en profundidad, leyendo multitud de libros, muchos posts y artículos sobre buenas prácticas y buscando y analizando los módulos más populares o maduros para incorporar toda la funcionalidad.

A continuación cuento un poco mi experiencia que básicamente se basa en la pregunta recurrente de cómo hago esto y ahora cómo hago esto otro aún mejor y así hasta que el proyecto comienza a alcanzar cierta madurez, cuando todo el trabajo realizado comienza a converger en algo más palpable y empieza a verse un proyecto que ofrece cierta utilidad, o eso es al menos lo que esperas.

He utilizado una aproximación lean al proyecto, esto es, voy a cerrar un conjunto de funcionalidad muy bien definida y después es el mismo proyecto el que va a validar con los usuarios (los primeros son siempre tus amigos y familiares) si es de alguna utilidad..., si hay que seguir (;-), pivotar (;-| o comenzar otra cosa distinta (;-(.

Me fascina la aproximación lean, ya que en realidad construyes experimentos que después el mercado valida. Si no sabes qué es la aproximación lean de proyectos, comienza leyendo el libro clásido de Eric Ries.

En cuanto a los módulos que estoy usando, los agruparé funcionalmente.

En el core de la aplicación, puedo desglosar los siguientes módulos principales:

• ​Express como framework para lo esencial de una aplicación web. Prácticamente es lo estándar en el mundo NodeJS y posee una enorme constelación de middlewares para la gestión de sesiones (express-session), gestión de los parámetros de un request o post (body-parser), cookies (cookie-parser), enrutado (lo gestiona directamente express), seguridad (protección CSRF con csurf), etc. Aunque hay otras opciones más flexibles, he usado ejs como herramienta de plantillas. También he usado compression para el envío comprimido de los contenidos en cada request.
• Compresión de ficheros con archiver.
• Gestión de imágenes con fabric.js (sí, tiene un módulo que permite usar fabric en el lado del servidor) así como canvas.
• Obtención de valores únicos y hashs con node-uuid, hashids (para la generación elegante de enlaces cortos) y md5 (para crear valores hash a partir de cadenas de texto).
• Framework para logueo de usuarios con Passport; sus extensiones te permiten integrar fácilmente loguee con Facebook, Google+ o Twitter.
• Q como librería para usar promises y evitar el anidamiento de funciones asíncronas (callback hell) que impiden escribir un código legible.
• Cliente para usar Redis como servidor de objetos de caché y almacenamiento en ella de sesiones de usuario.
• Search-index como mecanismo sencillo y útil para indexar los contenidos del site y poder realizar búsquedas.
• Módulo cliente de Sendgrid para el envío de correos electrónicos usando ese mailer.
• cron para gestionar la ejecución de operaciones recurrentes de gestión y mantenimiento del site.
• winston como librería avanzada para mensajes de log.
• Para escribir código más legible y mantenible, he usado profusamente lodash (esto es una oblicación para cualquier desarrollador que use javascript, aunque hay otras opciones similares).
• html-minifier para la minificación de contenidos al ser enviados en cada request.

No es que haya elegido todos esos módulos al azar, sino después de un proceso y trabajo de prueba, evaluación y experimentación, así como leyendo muchos blogs y viendo lo que la comunidad usa con más frecuencia.

¿Y qué hay de las pruebas? Ningún proyecto software puede considerarse maduro y profesional si no está respaldado por pruebas.

Para ello he usado, cómo no, chai como librería de asersiones y mocha para la ejecución de las pruebas. El resultado y la experiencia con ambas librerías ha sido y es magnífico.

El site gestiona multitud de ficheros de diverso tipo (no, no es una página más de enlaces y descargas...), de modo que después de evaluar diversas opciones cloud como CDNs me decanté com Amazon AWS y su paquete aws-sdk para la integración de su API REST en NodeJS.

Del mismo modo, el site se apoya en una base de datos MySql, para lo que he usado el cliente mysql para su integración con la aplicación.

El desarrollo de una aplicación no consiste sólo en hacer que esta funcione, más o menos respaldada por pruebas: también hay que definir flujos de trabajo para generar los assets del proyecto que finalmente serán desplegados en producción.

Para ello he usado, cómo no, grunt y muchos módulos básicos para generar la aplicación para su despliegue. Aunque su mismo nombre indica su propósito, a continuación indico los más relevantes:

Como muchas veces he cometado en este blog, trabajar bien, generar un resultado de calidad en tiempo y sin necesidad de que los equipos de trabajo estén estresados continuamente, es más una cuestión de organización que de excesos de horas delante del ordenador. Cuando las horas extras dejan de ser puntuales y pasan a ser crónicas, evidencian un problema grave de planificación y productividad, no hay más.

No obstante, veo continuamente cómo se sigue abusando del correo electrónico para gestionar tareas con una lista interminable de replies y cómo se usa el Outlook o el Gmail como almacén documental; también veo a menudo cómo se usa el excel como herramienta para planificar el trabajo...

Digamos que aunque hablamos mucho de la sociedad del conocimiento y que todos tenemos acceso a ordenadores, portátiles, smartphones, etc., ciertas cosas se siguen haciendo igual que en los noventa, es decir, que apenas se sale del correo electrónico y el paquete ofimático de turno.

A estas alturas, gestionar las tareas de un equipo usando exclusivamente el correo y hojas en excel, no es que esté obsoleto, sino que revela una falta de productividad o una inercia total de la gente que los usa abusivamente sin querer encontrar opciones más apropiadas y más ágiles. Lo siento si tu jefe o manager se organiza así, toda su desorganización terminará afectándote de un modo u otro.

Hay que sustituir el uso (abuso) de esas herramientas por otras cuyo propósito es el de gestionar proyectos o tareas y además tienes que definir tus propios flujos de trabajo. El uso de cualquier herramienta para gestionar tareas viene después de que tengas claro cómo organizas tu trabajo (flujos de trabajo).

La cuestión no es en realidad qué tareas hacer en cada momento o en los próximos días o semanas, sino de qué modo gestionas tu tiempo.

No, el correo electrónico no es:

• Un repositorio de documentos para su control de versiones.
• Un sitio donde recordarte lo que tienes que hacer.
• De ningún modo es la herramienta para generar informes que algún día tendrán que ser rescatadoss
• No es una herramienta para sustituir sesiones de brainstorming a la hora de definir detalles de un proyecto

Del mismo modo, en cuanto al excel:

• No es para gestionar tareas entre los miembros de un mismo equipo.
• Mucho menos para gestionar las fases de un proyecto.
• Es un desastre cuando varias personas intentan editar a la vez el mismo documento...

Sí, parece evidente que abusamos de esas herramientas y en realidad son el estándar de facto con las que la mayoría de la gente se organiza, me temo.

Aunque mejor eso que nada: la gente más estresada y víctima de la ansiedad en su trabajo y en el día a día suelen ser las que intentan llevarlo todo “en la cabeza”, las que no se paran un segundo para priorizar porque perciben que todo es urgente, las que desconfían de pararse un segundo y preguntarse a sí mismas ¿cómo puedo gestionar mi tiempo y mi trabajo algo mejor?.

La cabeza es muy mala aliada para gestionar la sobrecarga de trabajo, porque:

Tendemos a magnificar en la mente la mayoría de las tareas, sobre todo aquellas sobre las que aún no hemos reflexionado. Cuántas veces le he estado dando vueltas a la cabeza a algún asunto que al final se ha resuelto en menos de una hora...

La mente no prioriza bien: para priorizar hay que pararse sosegadamente un rato y ver pormenorizadamente todos los asunto que tienes abiertos y los compromisos (si es que no se te olvida ninguno).

Del mismo modo, la mente no es una agenda, tendemos a olvidar cosas.

El intentar llevarlo todo con la cabeza es la principal fuente de estrés, ansiedad y al final de la cadena falta de productividad. Por tanto, hay que “sacar” de ella todas las tareas que tenemos pendientes.

Desde hace años utilizo herramientas que te permitan gestionar fácilmente las tareas que tengo pendientes y uso esas mismas herramientas para planificar mi trabajo; lo mejor de todo es que existen varias opciones más o menos populares que además son gratuitas con funcionalidad más que suficiente.

Es absolutamente liberador cuando no tienes que rebuscar en la mente qué hacer en cada momento (con la sospecha de olvidar algo importante) y recurrir tranquilamente a tu gestor de tareas.

Existen muchas opciones, yo particularmente llevo mucho tiempo usando Wunderlist (incluso para las cosas de mis hijas y de casa).

Desde no hace mucho he comenzado a usar Trello, más orientado a la gestión de proyectos en el que participan varias personas y me ha sorprendido gratamente. Aunque, como digo, existen muchas opciones más:

• Asana, también orientado a la gestión de proyectos
• Todoist, más centrado en listas de tareas
• Nirvana for GTD, implementación para poner en marcha el método Getting Things Done (de David Allen)
• Evernote
• Taco

¿Qué conseguimos parándonos un momento y organizar nuestras tareas (o las del equipo que gestionamos) en cualquiera de esas herramientas? Lo primero que consigues es que percibes que tienes el trabajo “bajo control” y que no se te escapa nada, al menos nada importante.

Yo siempre digo que malo cuando no sabes en qué vas a estar trabajando en las próximas semanas. El buen trabajo no se improvisa, se planifica.

Por otra parte, visualizar de un modo gráfico todos tus proyectos, su estado actual y las tareas pendientes te permite encajar mejor desviaciones o asuntos imprevistos.

Es reconfortante cada vez que haces “clic” en algunas de las tareas que tienes pendiente para marcarla como completada, es como si hubieses dado un paso adelante. ¡Trabajo terminado!

El tener las tareas bien identificadas y definidas de la manera más concreta posible te permite además aprovechar esos huecos que surgen en casa o fines de semana. Si en ese momento te tienes que parar un momento para pensar qué hacer, seguramente termines haciendo algo de lo que más te apetece en ese momento, no lo más prioritario o importante. Casi nunca podemos avanzar en cualquier tipo de proyecto haciendo por capricho lo que nos viene en gana en cada momento.

Así las cosas, es mejor usar el típico excel y abusar de tu correo electrónico para gestionar tu trabajo que no usar nada, mucho mejor usar alguna herramienta web o un conjunto de ellas para gestionar, planificar y organizar tu trabajo y el de los demás, pero aún mejor, por encima de todo lo anterior, lo mejor es trabajar con tu propio workflow o flujo de trabajo bien definido.

Al final, cuando tienes una lista de tareas, estas han surgido “a partir” de un modo de trabajo particular, ese flujo de trabajo lo tienes que definir tú mismo e intentar adaptarlo para cada tipo de proyecto o circunstancia. En otras palabras, el modo en que usas cualquier gestor de tareas es una consecuencia de tener flujos de trabajo bien definidos.

El tener tu propio conjunto de workflows te permite no tener que pensar en cada momento cómo gestionar cada nuevo trabajo o tarea que te llega, sencillamente le aplicar el flujo de trabajo habitual; por poner algunos ejemplos de mi día a día:

• Si surje una tarea que puedes terminar en menos de dos o tres minutos, la haces inmediatamente. Esto parece una tontería, pero así vacías aún más tu lista de tareas mental y la de la herramienta que uses.
• Cada vez que identifiques una nueva tarea, al anotarla indica también cuándo debe estar terminada. Esto no es una trivialidad, sabemos que las tareas que no tienen fecha de finalización o se hacen al final o sencillamente nunca se hacen…
• Revisas el estado de las tareas al menos dos veces al día: al inicio de tu jornada laboral y al final. Este trabajo te permitirá reordenar si es necesario la prioridad de las tareas según las circustancias y además terminas tu jornada laboral con una idea clara de lo que harás al día siguiente (así le das oportunidad al subconsciente de ir trabajando en segundo plano…)
• Las tareas deben estar suficientemente concretadas para poder comenzarlas y terminarlas sin tener que saltar a otras cosas en medio. Nada peor para la productividad que intentar hacer varias cosas a la vez. Si una tarea te puede llevar muchas horas, divídiles en otras más concretas y pequeñas.

Esto no es más que un ejemplo, aunque lo importante es que si tenemos esa foto fija de lo que tenemos entre manos, nos liberamos de la típica sensación abrumadora de no tener tiempo para hacerlo todo, sabiendo priorizar en cada momento y sabiendo distinguir lo importante de lo urgente. Es más, seguramente no llegues nunca a tener asuntos “urgentes” porque estos eran antes importantes y se realizaron en el momento correcto.

Me gusta aplicar conceptos de desarrollo personal y coaching a mi trabajo como desarrollador de software y director del departamento que dirijo.

O pasamos tiempo teorizando, divagando y leyendo sobre esto y aquello (y seguramente llenando la cabeza de mucha información), o bien intentamos integrar en la acción todo eso, en el día a día, en las cosas que realizamos; si no lo hacemos así, en mi opinión perdemos el tiempo a no ser que te tomes esa avalancha de información como simple ocio: puedes leer un libro magnífico de lo que sea, no sé, como este en el que estoy ahora enfrascado sobre metodología lean en experiencias de usuario, pero si no aplicas lo que lees, no llegarás nunca a ningún tipo de conocimiento.

El conocimiento surje de aplicar lo que has aprendido. Generalmente confundimos verdadero conocimiento (experiencia) con una saturación total de información que nos impide realmente centrarnos y profundizar en nada.

Me temo que pasamos demasiado tiempo llenando la taza de información inútil y muy poco tiempo consiguiendo ese verdadero conocimiento que es el que nos resulta útil y práctico para hacer cosas. Yo siempre lo digo, no nos pagan para aprender cosas, tarea, por otra parte, infinita, sino por hacer cosas. Hay que leer, asistir a cursos y seminarios, claro, pero eso no basta; hay que aplicar en proyectos, sean profesionales o personales, todo eso para realmente adquirir ese conocimiento y experiencia.

Me encanta la teoría de la última milla: alguien que practica jogging y que quiere superarse cada vez más, conseguir mayores distancias, no lo consigue de un día para otro, sino paulatinamente; una vez has alcanzado la distancia que te has propuesto, no pares ahí, sigue, continúa aunque sean quinientos metros más o un kilómetro. En otras palabras, cuando ya has conseguido el objetivo que te has propuesto, continúa un poco más.

Ese poco más es el que te diferencia del resto, de los demás, de la competencia, y es lo que te permitirá superar tus limitaciones personales.

La excelencia o el trabajo bien hecho no consiste en un único aspecto que hay que cuidar, sino en todo lo que conlleva ese trabajo, desde la documentación, la calidad de las pruebas, incluso la calidad de las noticias en la web que hablan de ese proyecto. Como leí una vez, "como haces algo, así lo haces todo".

¿Cómo podemos aplicar la teoría de la última milla en nuestro trabajo como desarrolladores o en nuestro día a día laboral?

A continuación sugiero algunas de las cosas que yo hago, que no es que las haya leído y ahora me sirva para escribir esto o quedar bien con mis amigos o los clientes a los que intentamos vender algo, no, es lo que practico casi a diario desde hace años.

Puedes aplicar la teoría de la última milla cuando:

• Terminas de escribir un sencillo correo y antes de enviar te paras un momento a repasarlo; seguramente encuentres alguna expresión a mejorar y alguna falta de ortografía. Para mí esos detalles son importantes porque el destinatario se va a sentir importante si lee un contenido bien desarrollado o ninguneado si percibe que has escrito deprisa sin ninguna atención a los detalles. Hacer esa revisión te puede llevar menos de un minuto. Odio esos correos rápidos, llenos de faltas y que hay que leer dos veces para enterarte qué quiere decir.
• Has terminado el conjunto de pruebas que tenías previsto para comprobar cierta funcionalidad; antes de hacer el commit, el check-in o lo que sea, seguro que puedes dedicar treinta segundos a buscar un nuevo caso de prueba o ese pequeño refactoring que mejora la calidad de esas pruebas.
• Estás incluyendo las historias de usuario que se van a implementar en un próximo sprint de trabajo. Antes de darlas por concluidas, seguro que al repasarlas se podrán describir algo mejor, aunque sólo sea un poco.
• No hace mucho tuve que realizar una nota informativa de uno de nuestros productos para nuestros clientes; después de darla por finalizada, la llegué a leer hasta tres veces. En cada pasada siempre encontraba alguna expresión que mejorar o alguna pequeña errata. Estas revisiones no me llavaron toda una mañana, ni mucho menos, sino unos escasos quince minutos.

Este tipo de detalles que en sí mismos parecen insignificates por que por lo general te llevan muy poco tiempo, al cabo de la semana o del mes son muchos, cientos, de modo que se terminan acumulando y marcando realmente una diferencia en todo lo que haces. 

¿Alguna vez has pensado en algo que no sabes muy bien por qué pero parece como más profesional? Seguramente sus creadores hayan incorporado la teoría de la última milla como un hábito en su día a día, de modo que de manera casi imperceptible, su trabajo alcanza un nivel mayor de calidad.

Ese hábito de llegar un poco más allá no te va a proteger de cometer errores o de entregar algo cutre en alguna ocasión, pero desde luego nos sirve para cometer menos pifias y mejorar la calidad de todo lo que hacemos.

En software ocurre que no hay una misma respuesta para cada situación, para cada proyecto en el que cambia el número de personas involucradas en el equipo, la complejidad del mismo proyecto e incluso las tecnologías usadas. No obstante, lo que sí es cierto en todos los casos es que si se deja para el final el despliegue del sistema en un entorno lo más parecido o idéntico al de producción, nos encontraremos con muchos, muchísimos problemas.

Hay que desplegar en un entorno de producción lo más parecido al del cliente final tan pronto como se tenga alguna funcionalidad terminada pero completa, aunque sea simple.

Incluso si contamos con un entorno de integración fantástico y una gestión de la configuración para él magnífica, esto no nos garantizará que todo funcionará de maravilla en producción. Se podría escribir un libro entero sobre este tema, dependiendo de la naturaleza del proyecto e incluso del equipo, aunque me temo que casi nunca se tiene en cuenta el despliegue final hasta... ¡el final!, momento en el que nos podemos llevar muchas sorpresas.

Si no lo hacemos así, si no pensamos en el despliegue desde el principio, la brecha que nos encontraremos al final del proyecto cuando creemos que lo tenemos todo casi terminado, no hará más que agrandarse.

Un caso extremo de esto es cuando desarrollamos el proyecto en la misma máquina del cliente final..., llegando al caso de que fuera de él el proyecto requiere de una auténtica reingeniería (...) Esto, en software, es casi un pecado capital, al igual que probar contra bases de datos en producción o dispositivos que están en clientes finales. Vale sí, si hay que hacerlo, pues se hace cuando no haya más remedio, pero al menos tengamos en cuenta las consecuencias que puede tener.

Estas son las razones por las que opino que hay que publicar el proyecto en un entorno, llamémosle de pre-producción, lo antes posible.

Lo habitual es que un entorno de producción (= entorno que usará finalmente el cliente para usar nuestro proyecto) no tenga nada que ver con el entorno de desarrollo local que solemos usar. Eso es trivial y hasta frívolo decirlo, pero hasta que no sufrimos las consecuencias no nos damos cuenta de que muchas veces los SDKs que tienes en local y que no estarán en producción resulta que son imprescindibles, la configuración de una base de datos en producción puede que no sea la misma que la que tú usas en desarrollo (o incluso puede que sea hasta una versión diferente), la configuración del servidor o destino final puede que no tenga nada que ver con el entorno de los desarrolladores, sólo por poner unos ejemplos.

Es también corriente no detectar ciertos cuellos de botella porque en tu máquina local, al estar todo en el mismo equipo, todo va como la seda, con conexiones locales a la base de datos, si es que usas alguna, sin tener en cuenta la latencia que puede haber en ese punto si en producción la base de datos no está en local, está accesible remotamente o incluso el motor de base de datos es compartido, como suele ocurrir en diversos entornos.

Si se trata de una aplicación con una interfaz de usuario web, en local difícilmente vas a detectar problemas de rendimiento al cargar una simple página al no tener minimizados y concatenados los ficheros css y javascript. Eso sí puede ser un problema en un entorno real.

Hasta en entornos de alto nivel como .NET puede pasar que ciertas cosas funcionen a la perfección en modo debug y fallen de alguna manera inesperada en modo release, ¿sorprendido?

En local, en tu estación de trabajo, sueles tener a mano toda la información o trazas de cualquier cosa que ocurre en el sistema, ¿nos hemos asegurado de que en producción existe la misma trazabilidad? ¿Cuando algo falle, tendremos las herramientas necesarias para averiguar qué pasa en cada momento?

Hasta aquí comento muy por encima lo que podría ocurrir una vez el proyecto lo tienes desplegado, pero, ¿seremos capaces de desplegarlo todas las veces que haga falta? En otras palabras, debemos contar con una guía de despliegue que nos indique:

• El software base que debe estar preinstalado, versiones y su configuración (como Apache, IIS, node, SqlServer, MySql, Nginx, frameworks, Redis, etc.)
• Ubicación exacta de dónde se deben publicar todos los artefactos del proyecto. Esto es de vital importancia cuando esperamos publicar el proyecto en más de un cliente. Nada peor que tener algunas cosas por aquí y por allá y según la máquina de cada cliente, esto puede volver loco a quien le toque el mantenimiento (lo que equivale a una falta total de productividad)
• Pruebas finales que nos aseguren que todo está funcionado y en marcha. Estas no son pruebas unitarias o de integración, sino pruebas aunque sean manuales para garantizar que todo debería estar funcionando correctamente. Comúnmente este tipo de tests se llaman de validación y según qué proyectos los puede realizar el mismo cliente final para dar el ok definitivo al sistema.

Quizá suena un poco agorero todo lo anterior, pero es algo habitual que si no todo, gran parte de lo que he descrito te haya pasado en alguna ocasión.

La forma de evitarlo es ver el despliegue no como algo que se hace al final del proyecto, sino asumir la guía de despliegue como un artefacto más del mismo desde el primer momento. De esta forma, esta guía y sus actualizaciones a lo largo del desarrollo del proyecto nos permitirá avanzar en el mismo desde el primer momento de manera sólida, garantizando que la funcionalidad que tenemos hasta ahora, funciona tanto en los entornos de trabajo o de integración como en los entornos finales. Si tenemos suerte y el sistema hay que desplegarlo en veinte clientes nuevos, entonces ni tú o la persona encargada tendrá que pensar demasiado al estar todo documentado en esa guía de despliegue.

En mi opinión, la existencia de una guía de despliegue para cualquier proyecto es una síntoma de calidad.

¿A quién no le han pedido alguna vez que ponga en marcha un proyecto a partir del código fuente del mismo, y nada más? Terrorífico.

Quizá por el entorno laboral en el que me muevo o por el tipo de productos software específico en el que trabajo, veo desde hace unos años una tendencia imparable; sí, ya sé, ni la nube es algo nuevo y tampoco es una moda que todo el mundo olvidará dentro de unos años. Lo que quiero decir es que más allá de titulares y opciones disponibles para desarrollar software, comienzo a ver en el día a día un interés real sobre todo lo relacionado con soluciones en cloud entre los clientes y las empresas que les proveen de soluciones software.

La razón de esto es sencilla: costes más reducidos y plataformas de servicios en la nube muy maduras que comienzan a ser bien conocidas por las empresas que desarrollan software.

Tenemos actualmente clientes que utilizan nuestros productos en modo Saas (software as a service) desplegado en la plataforma de computación en la nube de Microsoft, Azure, y la verdad, la experiencia desde hace dos años es extraordinaria.

Realmente estamos viviendo un cambio de paradigma en el desarrollo de productos software, muy real y muy a tener en cuenta entre aquellos que ahora mismo se están formando para esta profesión, aunque lo que quiero destacar aquí es que contrariamente a lo que algunos creen, programar para la nube no tiene en absoluto nada que ver con programar una solución para su despliegue en equipos locales en los que tú mismo o alguien de tu empresa administra.

Programar para la nube es además poder usar una serie de servicios que sólo están disponibles en esa infraesctructura y que afectan a la naturaleza de tu aplicación.

Es verdad que una aplicación para escritorio o con una interfaz de usuario web la puedes desplegar en una infraesctructura en la nube (con Azure, Amazon AWS, Rackspace, etc.); sin embargo la nube ofrece muchísimos más servicios para el desarrollo de aplicaciones. Utilizar los servicios que todos esos proveedores te ofrecen no es sólo tener un medio sencillo para hostear tu aplicación, es muchísimo más.

Si decides comenzar un nuevo sistema desde cero teniendo en cuenta algunos de esos servicios, la anatomía de tu aplicación será muy distinta que si usaras otro tipo de infraestructura.

Azure es desde luego el servicio que mejor conozco, aunque he hecho pruebas para algún proyecto prototipo con Amazon AWS y Rackspace con una percepción muy positiva.

Hablar de la nube es también hablar de escalabilidad a un coste razonable e infraestructura para almacenar datos de manera masiva. La explosión de todo lo relacionado con el big data y el Internet de las Cosas (IoT) no serían posible si no existieran servicios de computación en la nube a unos precios realmente asumibles para muchas compañías. Es más, la tendencia es que los precios vayan bajando cada vez más.

En Azure, por ejemplo, me gusta en especial todos sus servicios de almacenamiento masivos; según las necesidades de tu aplicación, puedes optar por una base de datos relacional administrada (Sql Azure) con distintos sabores de rendimiento, un servicio de almacenamiento de tablas no relacional para almacenamiento masivo de información sencilla con particionado automático (table storage) y también almacenamiento masivo para ficheros (para disponer de tu propio CDN, etc.). Esto es sólo la punta del iceberg y un sencillo ejemplo, aunque lo importante es que todos esos servicios están accesibles a través de una API que puede ser accedida por distintas tecnologías y lenguajes (C#, Node.js, php, etc.).

Ya no se trata sólo de programar bien, saber plantear las mejores arquitecturas eficientes, simples y mantenibles para una solución en concreto; además hay que conocer todas esas posibilidades de despliegue hacia las que se está moviendo el mercado. El éxito de un producto software no está sólo en su desarrollo, también en encontrar una solución de despliegue eficiente, mantenible y al menor coste.

Con un mercado que puede ser global, lejos quedan los tiempos en los que hacías un portal web hosteado en un servidor dedicado sin pensar demasiado en qué pasaría si el número de usuarios creciera diariamente un 5%...

Lo interesante de todo esto no es que los servicios en la nube están disponibles sino qué cosas seremos capaces de hacer con esos servicios económicamente asequibles para crear nuevos tipos de soluciones.

Este paradigma de desarrollo tiene un gran impacto no sólo en lo que nos afecta a los desarrolladores de software, responsables de proyectos o aquellos que como yo, tenemos la responsabilidad de elegir las mejores tecnologías para lo que desarrollamos; también afecta a la economía real al escalar procesos y crear nuevos mercados donde antes no los había.

En mi opinión, y por poner un ejemplo, todas las plataformas, soluciones y propuestas relacionadas con la economía colaborativa tienen mucho que ver con poder ofrecer sistemas muy escalables (con miles o millones de usuarios) a un coste que hace pocos años sólo se lo podían permitir grandes multinacionales.

La economía colaborativa no es una entelequia para gente alternativa, es una realidad creciente y más que apreciable en nuestro día a día y si no que se lo digan a Albert Cañigueral, cuyo magnífico libro recomiendo.

Esta es una de las cosas más difíciles de resolver cuando afrontamos la creación de un nuevo proyecto: distinguir claramente entre qué debe hacer de cómo se debe hacer.

El "qué" está relacionado con requisitos, especificaciones, historias de usuario, todo aquello que nos haga entender lo que el cliente quiere, su problema a resolver.

El "cómo" tiene que ver con las tecnologías que van a resolver ese problema que el cliente nos plantea, en otras palabras, el cómo abarca desde las tecnologías a usar, metodología, evidencias a entregar hasta dónde se desplegaría el proyecto final.

Hay una confusión tremenda entre esa separación de conceptos, hasta el punto de tener que forzar o usar mal tecnologías mal elegidas para el propósito indicado en una sencilla especificación (cuando no se le dice a un cliente que "eso no se puede hacer").

Si ya es difícil extraer al comienzo todos los requisitos y conseguir que estos estén descritos con buena calidad y que sean entendibles, más complicado aún el elegir ese cómo a partir de todo lo anterior.

De cómo se gestione esto y las decisiones que se tomen en ese momento dependerá en gran medida la calidad del proyecto que se entregue, su coste final y su facilidad de mantenimiento y evolución. Errores en esta fase hacen que el proyecto termine en un completo fracaso o haya que tirarlo al cabo de algunos años.

Lo peor de todo es que en muchas ocasiones confundimos requisitos objetivos, indicados o no por un cliente o intermediario, con aquellas tecnologías que nos gustaría usar porque sí o bien porque son las únicas que conocemos bien y no queremos salir de nuestra zona natural de confort. 

Traducido al desarrollo de proyectos software, esto viene a ser algo así como empezar la casa por el tejado: si antes de afrontar un nuevo proyecto, sea del tipo de que sea, ya estamos diciendo que lo vamos a hacer con una base de datos en SQL Server, ya estamos levantando paredes en el laberinto que se formará durante su desarrollo, o dicho en otras palabras, en lugar de solucionar, estamos poniéndonos a nosotros mismos obstáculos.

Este no es que sea un error más, el confundir qué se tiene que hacer con cómo se debe hacer, sino que es un error paradigmático de una profesión tanto si a ella llegan gente titulada con uno u otro título académico o intrusos sin formación formal relacionada (sin ánimo de menospreciar a nadie, al fin de al cabo sólo valen el talento de cada cual y el trabajo bien hecho).

Este error clásico, de libro, consiste en forzar el uso de un conjunto de tecnologías para una solución sin hacer el ejercicio intelectual previo de validar si esas tecnologías son las adecuadas o no para ese tipo de proyecto.

Las razones que hacen que caigamos en este error recurrente, en mi opinión, siempre son algunas de las siguientes:

• Por pura pereza: puesto que conozco mejor las tecnologías x, y o z, no me voy a molestar en aprender o indagar otro tipo de cosas que quizá serían más convenientes para este proyecto.
• Porque la política de la empresa es trabajar con tecnologías de x, sí o sí y no hay que darle más vueltas.
• Porque en la estimación del esfuerzo, no hay cabida para incluir una curva de aprendizaje en nuevas tecnologías más apropiadas para ese nuevo trabajo.
• O lo que es peor todavía: porque me gusta la tecnología x y quiero jugar con ella, ahora tengo la oportunidad, valga o no valga para el proyecto en el que me han metido, así por fin puedo jugar con ella a costa de mi trabajo en la empresa, aunque el resultado sea penoso.

En cualquier caso, las consecuencias de no hacer ese ejercicio previo antes de lanzar a un equipo de desarrollo a construir una nueva solución, son malas y a veces catastróficas.

Sin ir más lejos, en el último año he visto cómo se ha tirado a la basura la solución inicial, pero ya en explotación en una gran compañía eléctrica, para rehacerla completamente con tecnologías más apropiadas para el escenario que se planteaba. De este modo vemos que el no considerar ese aspecto del software al comenzar un nuevo proyecto tiene un coste económico que alguien tendrá que pagar, tu propia empresa o tus propios clientes (encareciendo tus servicios y perdiendo así oportunidades competitivas).

Esto ocurre en pequeñas empresas, pero también en esas que llamamos grandes, con recursos suficientes para hacer todas las auditorías del riesgo del mundo...

Hay que preguntarse siempre y justificar al máximo posible si es conveniente o no usar ASP.NET MVC o cualquier otro framework para interfaces de usuario web en el contexto de un proyecto particular, si es mejor AngularJS o Backbone, si es necesario o no una base de datos relacional (MySql, SQL Server, etc.) o repositorios de información no estructurada (MongoDB, Cassandra, Amazon Simple DB, SQL Tables de Azure, etc.). 

No toda tecnología es adecuada para cualquier tipo de proyecto. Esto parece una obviedad, pero el modo en que veo que en ocasiones se elige qué emplear en cada proyecto me da muchísimo que pensar, cuando no esa motivación nace de la última moda...

En mi opinión, esta debe ser una decisión del líder técnico del proyecto, si es que lo hay, ya que sólo se puede aproximar a una solución adecuada si cuentas con suficiente experiencia y si conoces en alguna medida todas las posibilidades tecnológicas existentes que podrían dar solución a un proyecto en particular.

No sé si es acertado o no, pero por esta razón me gusta promover dentro de la delegación de trabajo que dirijo sesiones internas y completamente desinteresadas en las que cada miembro del equipo expone algo que le interesa, tenga que ver o no con los proyectos que gestionamos en el día a día. Esas sesiones internas nos las preparamos en su mayor parte fuera del horario laboral, pero el resultado es que ampliamos así el acervo tecnológico existente y cuando nos llega algo que afrontar totalmente nuevo, tenemos, cómo decirlo, un horizonte más claro por haber tenido más contacto con un conjunto de tecnologias más amplio. Evidentemente esto requiere de un esfuerzo difícil de valorar, pero que aporta un valor intangible extraordinario en lo que hacemos, o eso creo.

En cualquier caso, el cliente nunca te va a pagar la curva de aprendizaje que necesitaría al comenzar con una nueva tecnología que desconoces, aspecto que distingue radicalmente nuestra profesión de otras: si intentamos repercutir en el cliente ese coste, seremos más caros y por tanto, más débiles de cara a la competencia.

Todo esto que en cierto modo no deja de ser sutil (porque sus consecuencias son difícilmente medibles); es algo con lo que tenemos que enfrentarnos queramos o no. A lo mejor si trabajas en una gran empresa donde alguien te dice con pelos y señales lo que tienes que hacer y cómo, los tiempos, etc., esta discusión sea irrelevante, pero la mayoría de desarrolladores se tienen que enfrentar a estas decisiones continuamente.