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 coreframework 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 estoahora 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:

Wunderlist sampleComo 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).

Trello logoDesde 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:

¿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.

No hace mucho he tenido que retomar un desarrollo que comencé hace año y medio y que después continuó uno de mis compañeros. A veces programamos pensando que nos vamos a acordar de todos y cada uno de los detalles de lo que hacemos cuando la realidad es que a los pocos días se nos olvidan sin poder evitarlo y a los meses casi ni reconocemos que esto o aquello los hiciste tú mismo. 

Para cada clase incluimos una sección de comentarios indicando el autor de la misma y su propósito, como manera rápida de identificar esa información; en ocasiones me cuesta mucho recordar que una clase concreta la comencé yo mismo... No es mala memoria (que también, quién sabe), aunque me consuelo diciéndome que es el efecto de haber escrito miles de líneas de código en los últimos años.

Con frecuencia se cae en el error de programar para solucionar algo ahora y sin tener en cuenta que hay que solucionarlo para siempre. Pero, ¿cómo medir más o menos objetivamente que algo está mejor resuelto para el largo plazo? O nos interesamos por los resultados a corto plazo o a largo plazo, el resultado en uno y otro caso no tienen nada que ver.

Al retomar aquel proyecto pude comprobar una vez más cómo escribir software de manera limpia, clara, sencilla y con una buena cobertura de pruebas te puede salvar de malgastar días y semanas de trabajo sencillamente retomando aquello que hiciste hace mucho tiempo. Lo contrario es acumular deuda técnica que te pasará factura tarde o temprano, o lo que es peor, tendrás a un compañero acordándose de tus propias chapuzas; sí, seguramente sea ese que cuando te lo cruzas viniendo del office te mira con mala cara, quién sabe.

Del mismo modo no siempre he podido trabajar tanto en el detalle, en encontrar la mejor solución y sé de sobra el resultado: malos trabajos que se entregan y que terminan empeorando con el tiempo.

Llamamos deuda técnica a todos esos detalles que vamos dejando de lado sin resolver del todo bien pero que cuando se acumulan, terminan en una solución difícil de evolucionar y mantener. Es algo malo, muy malo, como eso de acumular karma negativo... Es la pesadilla de cualquier desarrollador: el tener que asumir un proyecto que ha hecho otro y que no hay quien lo entienda, que está cogido con pinzas.

Lo habitual es que se trabaje dejando muchísima deuda técnica, y esto es así porque es muy difícil evaluar el impacto en tiempo y falta de productividad que produce meses o años después cuando el gestor de un proyecto (tu jefe, vaya), lo que quiere son resultados inmediatos (o sea, pan para hoy y hambre para mañana).

Como el jefe soy yo mismo (aunque suene mal decirlo), una de las máximas que sigo en los proyectos que desarrollamos es que las cosas se tienen que terminar limpias y claras; si de lo que se trata es de reducir riesgos (cosa que se entiende mejor en otros contextos de la compañía) entonces esto es así como una garantía para el futuro: reducimos riesgos refactorizando diseños, limpiando código y simplificando. Curiosamente, el intentar trabajar así no nos ha hecho fallar en ninguna fecha de entrega acordada, lo cual es buena señal.

Puesto que en esencia un proyecto se paga por tiempo dedicado a él, no siempre podemos pararnos todo lo que nos gustaría a hacerlo lo mejor posible. No obstante, mi opinión es que si te paras a tratar de reducir o eliminar esa deuda técnica, todo el tiempo que en ese momento pierdas lo recuperarás multiplicado más adelante.

También es habitual encontrarte con gente que resuelve rápido, pero la pregunta no es cómo de rápido trabajas en software, sino cómo de limpio y mantenible haces el trabajo que entregas. Todo esto suele ser muy sutil, subjetivo, difícil de evaluar, me temo.

En esta ocasión, a las dos horas de revisar lo que se hizo en su día, ya estaba en condiciones de estimar el tiempo que podríamos tardar en añadir la nueva funcionalidad requerida por uno de nuestros clientes.

No hay una varita mágica para llegar a crear un software que te permita asumirlo de nuevo con comodidad al cabo de algunos meses o años incluso, depende del tipo de proyecto y claro está, tu propia experiencia acumulada. Sin embargo, cuando se siguen unos simples principios durante toda la solución es mucho más fácil (y rentable) volver a trabajar en ella como en el primer día.

En este caso que comento, la varita mágica era básicamente lo siguiente:

  • Ese módulo a evolucionar seguía la arquitectura de diseño general de la solución. Nada de excepciones en el diseño alejado del general, las cosas estaban ahí donde un esperaba encontrarlas.
  • Las clases son suficientemente pequeñas como para percibir claramente qué hace cada una, qué propósito único resuelve y cómo encaja con el resto.
  • Las pruebas te permiten ver cómo se usa cada clase; los tests no sólo te sirven para saber si lo que has escrito funciona, también te permiten documentar el uso del código que generas.
  • La inyección de dependencias te permite localizar rápidamente dónde están definidas y cómo se ensamblan las partes inyectables de la solución. Si está bien planteada, una gran parte funcional del sistema será inyectable.
  • Ausencia total de código obsoleto o muerto (que nunca se ejecuta pero que a alguien le ha dado pena eliminar). Es decir, no hay basura que te distraiga de captar lo esencial.
  • Estructura de la aplicación extraordinariamente ordenada y entendible.
  • Nombre de métodos y clases claros y bien elegidos.

En ocasiones nos surge la pregunta de qué hacer cuando se está en una fase de definición o se tienen huecos de tiempo por llenar y que podrías usar productivamente. La respuesta está clara: siempre puede buscar aplicar todos los puntos anteriores a la solución en la que trabajas.

Para casi cualquier sección del código final, su calidad no surgió a la primera cuando se desarrolló hace algunos años, sino que es el producto de muchos refactorings y muchas fases de trabajo, algunas de las cuales tenían únicamente el propósito de mejorar la estructura interna y el diseño del sistema.

Quizá el mejor desarrollador no es aquel que rápidamente encuentra y resuelve cómo hacer algo; también es un magnífico desarrollador el que se para un momento para mejorar lo que ya funciona en algún aspecto, el que presta mucha atención a los detalles que nos permiten años después poder retomar fácil y cómodamente lo que hacemos ahora. Es algo así como dar un paso atrás para dar después un gran salto adelante.

Es ya muy antigua la polémica por la que un desarrollo software se debe considerar horroroso, decente, regular o magnífico, hay tantos puntos de vista como esas críticas contradictorias de cualquier película o la descripción de una misma noticia por varios periódicos con distintas líneas editoriales; es un factor también tremendamente subjetivo.

No obstante, de lo que sí podemos estar seguros es de que una solución que acumula mucha deuda técnica es bastante peor que aquella en la que no existe. La pregunta no es sólo ¿funciona o no funciona?, también ¿será fácil retomar esta aplicación en el futuro por alguien que ha participado en ella?

Como ocurre en muchos temas y como decía Benedetti: "Cuando creíamos que teníamos todas las respuestas, de pronto, cambiaron todas las preguntas". Según las preguntas que te hagas acerca del tipo de calidad que esperas en el software que desarrollas (¿es rápido, eficiente, usable, mantenible, de diseño limpio, traza bien los errores, etc.?) así será este.

¿Desarrollas pensando en el corto plazo o un poco más allá?

Ahora mismo se está viviendo una auténtica ola sobre el emprendimiento en mi país; no sé si en otros lugares está sucediento lo mismo. Lo que debería ser una actitud que se les enseña a los niños desde parvulario, ahora parece que lo estamos aprendiendo a marchas forzadas (por la urgencia de la crisis económica y financiera que llevamos arrastrando desde hace tiempo).

Revistas y publicaciones, programas de radio y televisión, másters y mucho libro de autoayuda para el desarrollo personal y coaching así como programas de apoyo al emprendedor están ahora por todos sitios.

Para mí todo esto es bueno porque supone que dejamos de pensar que los demás nos van a dar un trabajo y tomamos la responsabilidad de pensar por nosotros mismos, lo que en algunos círculos llaman el empoderamiento personal. Esta misma actitud es también muy positiva como empleado de una compañía, lo que se llama intraemprendedor, es decir, aquella persona que trabajando en una empresa innova o aporta ideas desde su ámbito de responsabilidad manteniendo una actitud proactiva continuamente, con él mismo y con todo lo que le rodea.

Los desarrolladores de software quizá tengamos más facilidades que otros profesionales para emprender en un momento en que todo el mundo mira a Internet y el paradigma económico impulsa la eficiencia y el uso masivo de dispositivos siempre conectados. De ahí que muchos desarrolladores tengan continuamente ideas que poner en marcha con las que intentar emprender un proyecto empresarial.

Programar bien y dominar tecnológicamente ciertas plataformas, no tiene nada que ver con emprender un buen proyecto que funcione comercialmente. Para esto hacen falta muchas otras habilidades que, por supuesto, se pueden aprender.

Lo que no es nada bueno es que se ignoren todas esas habilidades y conocimientos necesarios para montar comercialmente un proyecto. Me preguntaron no hace mucho qué pensaba yo al respecto y cuáles podrían ser los primeros pasos para pasar de la idea al producto, de modo que en esta ocasión me voy a extender un poco más de lo habitual y aportar mi granito de arena para al menos indicar todo lo que hay que tener en cuenta.

Hay cientos de libros, seminarios, cursos y hasta másters que cubren este tema, que, además, evoluciona igual que las tecnologías software. Por tanto, este post viene a ser algo así como una introducción acelerada al emprendimiento con proyectos software.

Por su extensión, he dividido este trabajo en las siguientes secciones.

De la idea al proyecto

En cierta medida, emprender es probar si lo que tienes en mente puede funcionar o no y encontrar un mercado para esa idea o producto. Si de lo que se trata es de probar algo y según los resultados obtenidos, evolucionarlo tantas veces como sea necesario, entonces todo esto huele un poco a ágil y a lean, a iterar sobre algo hasta conseguir un buen resultado.

Muchas veces los errores son grandes maestros. Allá por el 2008 tuve mi primer contacto con un proyecto y una idea emprendedora que fue un auténtico desastre a los pocos meses; la razón es que confundimos la idea con su realización, la amistad con un relación de compromiso en un proyecto común y, por supuesto, una ignorancia total sobre cómo darle cuerpo empresarial a lo que queríamos desarrollar, entre otros muchos errores... Ese primer proyecto fracasado lo recuerdo con cariño por todo lo que me enseñó; también es cierto que ahora se hace mucha apología del fracaso como herramienta de aprendizaje. Digo yo que en un punto intermedio entre la indolencia y el no fustigarnos al tropezar estará la virtud.

En cualquier caso, desde entonces han pasado muy cerca mía multitud de proyectos de conocidos, charlas en eventos sobre modelos de innovación y muchas, muchísimas lecturas al respecto. Igualmente proyectos personales con mayor o menor éxito.

Si estás pensando en poner en marcha una idea que implica el desarrollo de cualquier tipo de software me gustaría decirte que el desarrollo del mismo es tan sólo el centro de un universo de variables y tareas que hay que hacer bien, relacionadas o no con el software pero que sin ese universo tu idea no llegará a ninguna parte, me temo.

Como desarrolladores nos gusta dedicar gran parte de nuestro tiempo programando, creando artefactos que hacen algo, pero si desarrollamos un proyecto emprendedor basado en software, entonces no podemos ignorar dotarle de la estructura emprendedora correcta. Y, por supuesto, estar dispuesto a gastarte algunos eurillos... Esa coletilla de comenzaron sin nada es sólo un mito urbano que pudo funcionar para algún visionario pero de ninguna manera es lo general. No entiendo cómo alguien que dice creer en su idea después no es capaz de invertir en ella algo de dinero.

Veamos cuáles son esas piezas fundamentales en las que casi ningún emprendedor de software ilusionado apenas repara y ni le da importancia y, sobre todo, cómo algunas decisiones desde el punto de vista del software son fundamentales.

La idea, por evidente que parezca decirlo, sólo existe en la cabeza

¡Qué sorpresa! En otras palabras, lo que quiero decir es que si esa idea no sale de la cabeza cobrando vida mediante la acción, ahí quedará, como un ente mental sin valor. Para la mayoría de la gente, las ideas se quedan ahí dentro, sólo para unos pocos la idea es lo suficientemente fuerte para pasar a la acción.

En multitud de ocasiones pensamos idílicamente en un proyecto maravilloso, único, que podría funcionar, es decir, generar usuarios y clientes y por tanto, ingresos. Entonces hacemos planes de cómo hacer esto o aquello, sobre qué tecnologías usar (a menudo son siempre las que más conocemos), las posibilidades que se podrían abrir y un largo etcétera. 

En ocasiones, también, estas maravillosas ideas no son más que quimeras mentales para huir de una realidad personal o laboral que no te gusta. Esto lo he visto hasta la saciedad.

Si eres un iluso, quédate en el mundo de las ideas, pero sólo las que inducen a la acción, al trabajo y al esfuerzo, saldrán adelante.

No hace falta inventar un proyecto maravilloso y totalmente innovador: muchas veces, propuestas que parecen triviales y hasta aburridas son las que encuentran un mercado y una viabilidad.

En mi opinión existen dos momentos claves para pasar de esta fase (llamémosla de la idea al proyecto). La primera es sentarse tranquilamente a poner por escrito una descripción clara del proyecto, su misión, sus expectativas, etc. Poner por escrito todo lo que tenemos en la cabeza tiene un valor incalculable por la sencilla razón de que te obliga a definir cosas que hasta ese momento sólo eran entelequias un poco vagas. Muchas ideas no pasan de esta prueba...

Existen técnicas para pasar al papel una idea de proyecto, como la técnica del canvas (o lienzo), con herramientas online que te ayudan a su definición, como Canvanizer. Del mismo modo, los mapas mentales también ayudan en esta fase.

El segundo momento, si es que se ha superado el primero, es adquirir un compromiso con uno mismo. Ningún proyecto incipiente se va a desarrollar si antes no nos comprometemos personalmente con él, esto es, no nos comprometemos a sacar tiempo extra (quitándonos tiempo de ocio, de fines de semana, etc.). Sólo cuando hay compromiso personal es cuando se llega a algo. Lo sorprendente es que cuando crees en algo, no hay esfuerzo que valga, ya que estás deseando dedicarle tiempo.

Al menos eso funciona para mí: cuando hemos terminado una fase de un proyecto a tiempo, o realizado cualquier proyecto personal sea del tipo que sea, la mayor satisfacción me la produce el haber cumplido con un compromiso personal previo autoimpuesto.

El Arte de EmpezarSi este paso a la acción te cuesta trabajo necesitas urgentemente El Arte de Empezar de Guy Kawasaki.

Hay que validar la idea

Me gusta el enfoque lean en la realización de proyectos, sobre todo si son proyectos basados en software que viven en un mundo acelerado en donde los paradigmas cambian tan rápido. Lo que triunfa ahora es la disrupción. 

Vivir con menos (Albert Cañigueral)Hace poco he terminado de leer este maravilloso libro de Albert Cañigueral y de título Vivir Mejor con Menos, descubre las ventajas de la nueva economía colaborativa y, como me ocurre a menudo, no puedo evitar poner gran parte de las cosas que leo en relación a mi actividad como desarrollor de software y gestor de proyectos. 

Por decirlo en pocas palabras, me siento entusiasmado por toda la información que ofrece Albert en su libro y por las enormes oportunidades que se están abriendo ya en este nuevo paradigma económico que sutilmente se está abriendo paso poco a poco. 

La economía compartida (o sharing economy), por definirla brevemente, consiste en mantener una relación distinta con los objetos que consumimos y usamos: pasamos de relacionarnos con ellos en forma de propiedad a considerarlos como un servicio de intercambio, de ahí lo de consumo colaborativo.

Los paralelismos entre este concepto y Saas, Paas y Iaas (software / plataforma / infraestructura como servicio) son evidentes. De hecho, uno de los productos que comercializamos en la compañía para la que trabajo se ofrece como servicio con suscripciones periódicas y lo más sorprendente es que todos los clientes usan esta modalidad. No compran el producto, sino que pagan periódicamente por su uso.

Cuando se habla de economía compartida a uno se le viene a la cabeza Bla Bla Car o Airbnb (plataformas muy populares en mi país); no obstante, eso es sólo la punta del iceberg; lo más interesante de todo es que es una renovación de viejas formas de organización, quizá ancestrales, pero que con Internet como palanca su efecto es infinitamente mayor. Cuando hablamos de Internet, lo hacemos de software...

Gracias a infinidad de iniciativas que se están poniendo en marcha y todas a través de portales y aplicaciones móviles, se están desplegando todas las posibilidades de organizar una economía menos centrada en el hiperconsumo y más en la colaboración y la confianza entre los individuos. 

Quien piense que carreteras llenas de vehículos con un único conductor, por poner un ejemplo llamativo, es un futuro sostenible para nosotros y nuestros hijos, va por mal camino. Cambiar de un paradigma económico a otro ni sucede en dos días y además ocurre casi de manera imperceptible con tiempos en los que se solapan ambos para llegar a darnos cuenta de que en una o dos décadas hacemos las cosas de otra manera.

Para ello la economía no cambia porque sí, sino que lo hace porque antes ha cambiado la mentalidad de las personas.

Todo esto, como digo, lo están posibilitando infinidad de sitios en Internet como forma de comunicación básica, ¿cómo si no? Vemos cómo el trabajo de muchos desarrolladores, por tanto, no es sólo escribir software, también existe una responsabilidad ya que a través de esos desarrollos cambiamos la forma en que la gente se relaciona y también cómo puede evolucionar la economía. Aunque parezca grandilocuente, es así.

En ocasiones digo eso de que es un magnífico momento, quizá el mejor, para ser desarrollador profesional porque parte de la economía se está moviendo hacia lo digital. Sin embargo Albert en su libro indica que no queda ahí, sino que también la misma tecnología está modificando cómo nos movemos, relacionamos, consumimos y, en definitiva, está modificando la economía tradicional, el cambio es por tanto, recíproco. Apasionante. 

Tal y como afirma Albert, todo ello se está produciendo por la existencia de Internet, su uso masivo, la cultura digital, la omnipresencia de la tecnología y también por la crisis económica (que fomenta en las personas la necesidad de buscar alternativas que no dependan directamente de consumir con dinero).

La economía compartida es mucho más que poder compartir los gastos de coche en tus desplazamientos habituales, además:

  • Couchsurfing: conseguir alojamiento basado en la confianza entre individuos y tu reputación en la red. 
  • Carcharing y carpooling: no sólo compartes trayectos (como conductor o pasajero), también puedes ofrecer tu propio coche para que lo usen otros mientras a ti no te hace falta.
  • Alojamiento y alquiler de espacios entre particulares: ofrecer alojamiento a terceros en tu propia casa y tú mismo conseguir alojamiento gratis o de pago, siempre entre particulres y basado en la confianza. Esto incluye también el intercambio de tu propia casa con la de otro particular.
  • Coworking: ¿por qué no compartir los espacios de las oficinas entre distintas empresas o freelancers, reduciendo costes y además posibilitando el networking entre ellos?
  • Finanzas participativas como el crowdfunding (apoyo a proyectos) y el crowdlending (préstamos entre particulares), especialmente importante en aquellos países donde la crisis económica ha supuesto una enorme restricción en el acceso al crédito... Esto también incluye inciativas de ahorro colectivo.
  • Intercambio de divisas entre particulares, quitándote de enmedio al agente bancario con sus comisiones.
  • Monedas sociales virtuales, siendo el bitcoin como la más conocida aunque hay otras.
  • Bancos de tiempo: no hace falta comprar el servicio de alguien, puedes intercambiar lo que todas las personas tienen, que es ¡el tiempo!. Así le ayudas a tu vecino un día en algo y él a ti en otra ocasión, por poner un ejemplo.
  • Mercados de segunda mano: a mí por lo menos, me remuerde la conciencia cuando tengo que tirar algo que aún podría usar alguien pero que yo no necesito. Al revés también, ¿por qué no adquirir algo que necesitas y que necesariamente no tiene por qué ser nuevo? Reducimos así la fabricación continua de productos y los reutilizamos más antes de tirarlos a la basura.
  • Grupos de consumidores, compras colectivas, venta directa entre productor y consumidor y un larguísimo etcétera.

¿Ejemplos? Hay cientos y muchos con carácter local, por poner algunos en los que me he interesado especialmente: Comunitae y Lendico (para préstamos colaborativos), Home for Exchange (para el intercambio de casas entre particulares), BlaBlaCar y Carpooling (para compartir coche), Social Car (para alquier de coches entre particulares), Goteo, Verkami, Kickstarter e Indiegogo (para la búsqueda de financiación en proyectos), Puddle y TuTanda (como plataformas para el ahorro colectivo), Transferwise (para el intercambio de divisas entre particulares) y muchos más.

¿Alguien puede pensar que todas esas plataformas son sólo una prueba de concepto? Ni mucho menos, son realmente la cara visible de un nuevo paradigma con el que consumimos y compartimos de otra forma.

Yo creo que este movimiento, si es que se puede llamar así, no tiene marcha atrás y que es ahora cuando se están dando los primeros pasos. Con sus luces y sus sombras, lo que sí está claro es que una economía basada en el crecimiento ilimitado del PIB en un mundo cuyos recursos son finitos y donde el individualismo exacerbado vacía las farmacias de ansiolíticos y antidepresivos, este emergente paradigma económico no basado en el dinero exclusivamente y en la acumulación de bienes, sino en el intercambio y en el uso de esos bienes, nos acerca un poco más a esa idea de dejar el mundo algo mejor que como nos lo encontramos. No es idealista, es una realidad que poco a poco está cambiando cómo nos relacionamos y ahora cómo consumimos. Sí, estoy firmemente convencido de que el software (y nuestro trabajo) se puede poner al servicio de causas de ese tipo dándole mayor sentido a nuestro día a día.

¿Y a mí qué, si yo como desarrollador hago lo que me encargan?, podría pensar cualquiera. Sin embargo, este tipo de portales e inciativas que aspiran a cambiar la forma en nos relacionamos e intercambiamos bienes y servicios, implican conocer ciertas tecnologías para su desarrollo e igualmente introduce un componente social en los productos, por poner un ejemplo:

Trabajar en distintos ámbitos tiene algo de fascinante, terminas dándote cuenta de cómo lo que haces en uno enriquece los demás y al revés.

Ahora mismo estoy trabajando en un proyecto basado en MEAN que al mismo tiempo me está permitiendo sentar las bases de un proyecto de I+D que estamos realizando en la compañía para la que trabajo y que desarrollaremos durante 2015 y 2016; este proyecto consiste en un sistema de detección y diagnóstico de incidencias para el despliegue de cuatro millones de smart meters, de la mano de una compañía de distribución eléctrica nacional. Big-data con Hadoop, su despliegue en la nube con Azure, el análisis y explotación de esos datos más una capa de servicios que consumirán terceros sistemas serán las partes esenciales del proyecto y en cuyas tecnologías nos vamos a meter de lleno en los próximos meses.

¿Qué puede garantizar que tendremos éxito en ese nuevo proyecto reconociendo que algunas de las tecnologías que vamos a usar son relativamente nuevas para nosotros?

Si crees conocer muy bien la tecnología X, ¿qué te hace pensar que serás capaz de sacar provecho a otra totalmente distinta?, ¿te asegura acaso que vas a tener éxito con un nuevo stack que debes usar para un nuevo proyecto cuya naturaleza no tiene nada que ver con lo que has hecho hasta ahora?

Para un responsable de proyectos, ese es un riesgo que hay que considerar a fondo.

Un desarrollador de software o un equipo de trabajo sólo pueden tener éxito en cualquier proyecto si son capaces de mantener firmemente una serie de principios de desarrollo y métodos que se pueden aplicar a cualquier tipo de tecnología.

Por tanto, aún teniendo valor, me da siempre qué pensar cuando escucho afirmaciones del tipo "soy experto en C#", "nivel avanzado de administración de Sql Server", o "desarrollador front-end con AngularJS", etc, cosa que se suele ver en todos los currículums que me llegan (y por qué no, en el mío propio hasta hace pocos años). Todo eso es fantástico, pero no suficiente...

Si dominas una serie de principios serás bueno y tendrás éxito en cualquier proyecto software independientemente de las tecnologías que se usen.

Para mí, el currículum ideal de un desarrollador profesional de software estaría compuesto de afirmaciones de este tipo:

  • Participación activa en los siguientes proyectos:....
  • Experto en patrones de diseños y antipatrones.
  • Experiencia en enfoques ágiles para proyectos software.
  • Conocimiento sobre principios de diseño como inyección de dependencias, inversión de control, DRY, KISS, SoC y un largo etcétera.
  • Desarrollo con integración continua y cobertura total con pruebas unitarias y de integración.
  • Experiencia de análisis de calidad de código.
  • Habituado a refactorizar código y desarrollo de código limpio.
  • Experto en realizar código mantenimible y evolucionable.
  • Dominio de arquitecturas software escalables.
  • Conocimiento de principios de usabilidad en interfaces de usuario.
  • etc.

Aunque sólo son un ejemplo, todas esas aptitudes son mucho más importantes que dominar cualquier tecnología en particular: con cualquier lenguaje, sistema operativo, framework o entorno de desarrollo se pueden aplicar esas técnicas, principios y métodos impresindibles para generar productos software de calidad.

Cualquier desarrollador con dominio de todos esos temas va a seguir aplicándolos con cualquier nueva tecnología con la que tenga que comenzar a trabajar.

Aparte de una actitud positiva hacia el trabajo y buena disposición a trabajar en equipo, a lo anterior añadiría afirmaciones de tipo "Mis últimas lecturas técnicas han sido...", "Asistencia en el último año a eventos como...", "Participación en el blog X", etc. Aunque ya todo esto sería mucho pedir.

Es difícil, lo sé, cuando muchas compañías piden "expertos programadores en java", por poner un ejemplo, sin darse cuenta de que cualquier desarrollador mínimamente experimentado puede acercarse al mundo java con un par de semanas de estudio y dos o tres buenos manuales, aunque no por eso va a hacer un buen trabajo necesariamente. Sí va a hacer un buen trabajo si está habituado a implantar todos los conceptos anteriores con cualquier otra tecnología. Otra cosa es que los gestores de proyecto tengan claros ese tipo de consideraciones...

En cierto sentido, todo lo anterior es como la gramática y la ortografía necesarias para escribir una buena novela, en donde el saber escribir una palabra tras otra vendría a ser a conocer bien la tecnología X.

¿Sabes sencillamente escribir aunque tengas un buen vocabulario sin tener claras la gramática que nos permite generar un trabajo de calidad?

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

El libro negro del programador.com
Now available in english!

Archivo

Trabajo en...

Mis novelas...