Es ya recurrente en mis posts el insistir sobre el tema de la calidad en nuestro trabajo como único recurso para crearnos de verdad un buen currículum y una buena carta de presentación.

Aunque la calidad no deja de ser un concepto demasiado interpretable, en software viene a ser equivalente a que el sistema o aplicación que se entrega funciona según los requerimientos del cliente y, por supuesto, que no tenga fallos, que sea fácil de mantener, evolucionable, etc. Esto a mí me parece evidente aunque no siempre se tiene en cuenta en el día a día de un desarrollador.

Ahora bien, no siempre se ve claramente la relación entre la gestión de un proyecto software y el resultado final de este. En mi opinión no sólo es importante sino también determinante.

Desarrollar software no es sentarte ante un ordenador y pasarlo bien escribiendo líneas de código (bueno, también, pero lo que quiero decir es que no sólo es eso). Cuando tenemos que entregar algo para una fecha determinada, hay que planificar, cuando trabajamos en equipo las tareas hay que repartirlas coherentemente, o sea, hay que gestionar la carga de trabajo, cuando se ponen las bases de un nuevo sistema hay que tomar decisiones de diseño y antes de todo eso hay que tomar, interpretar y traducir al lenguaje del desarrollador las especificaciones de un cliente que en ocasiones no tiene del todo claro lo que quiere o necesita.

Todos esos puntos no son más que la punta del iceberg y absolutamente todos están relacionados con la gestión de un proyecto software, sin hablar de la responsabilidad que conlleva ya que ciertas malas decisiones pueden tener efectos catastróficos.

Ingenuamente hay quien piensa que eso de gestionar consiste en ordenar y mandar lo que otros tienen que hacer para sentarnos cómodamente a esperar que las cosas se hagan solas porque sí. Bajo esa concepción, el desastre de un proyecto software está asegurado.

Aunque hay tantas particularidades como proyectos y puesto que un proyecto de software tiene su propia idiosincrasia, básicamente cuando alguien se enfrenta a la gestión por primera vez no tiene una idea clara de lo que se espera de él.

Se aprende por mucha prueba y error (y estos a veces se pagan caro), pero, entre las habilidades esenciales que debe contar un buen gestor software están en mi opinión las siguientes:

  • Saber dar prioridad a la funcionalidad que se debe implementar en cada momento.
  • Mantener un equipo de trabajo coherente sabiendo cuáles son los déficits y mejores habilidades de cada miembro del equipo.
  • Potenciar las capacidades de cada miembro del equipo presionando (que no ahogando) lo suficiente de modo que una meta se convierta en un aliciente.
  • Crear una planificación con el tiempo suficiente como para compartirla con el equipo.
  • Nunca, absolutamente nunca, romper esa planificación (salvo ocasiones muy puntuales y con razones de peso), es decir, los desarrolladores debemos saber en cada momento qué tareas tenemos que hacer a un tiempo vista.
  • Mantener la suficiente paz de trabajo para que los desarroladores puedan estar concentrados de la mejor manera posible, lo que implica a veces pararle los pies a un cliente díscolo o discutir incluso con tu propio jefe (el jefe del gestor, digo). En ocasiones también supone no compartir esas ansiedades o inseguridades relacionadas con tu propia responsabilidad como gestor en donde existen otro tipo de problemas en relación al resto de la compañía que pueden no ser bien entendidas por los desarrolladores que diriges.
  • Mantener al cliente a raya, esto es, vigilar que este no cambia de opinión continuamente y que cualquier cambio en la especificación no está fuera de presupuesto, si es que se gestiona también el proyecto a este nivel.
  • Comprobar que se utilizan las herramientas elegidas y los flujos de trabajo definidos.
  • Conseguir que los desarrolladores trabajen en las mejores condiciones posibles, buenos equipos, formación adecuada, etc.
  • Comprobar que se mantiene la metodología de desarrollo elegida.

Y un larguísimo etcétera...

Cuando un proyecto software falla, el único responsable es el gestor del mismo, no hay más. Pocas cosas hay realmente que no se vean venir y parte de la responsabilidad de un gestor de un proyecto software es también gestionar riesgos, de incumplimiento, de calidad de lo entregado, etc. Si la cosa al final se tuerce, entonces tener la actitud valiente de reconocer los errores, aprender de ellos y asumir la responsabilidad. Tampoco es que te vayan a crucificar, pero si en momentos así somos inteligentes, aprenderemos mucho de los errores cometidos.

Lamentablemente no son pocos los casos en los que la única forma de ascenso laboral consiste en conseguir un puesto de gestión para el que quizá no se tienen las aptitudes adecuadas.

Se confunde en ocasiones un puesto de gestión (la verdad, qué mal me suena esto) con estar en una silla desde la que la gente hace lo que uno diga, cuando la realidad es que no tiene nada que ver con eso:

La responsabilidad de un gestor es gestionar recursos técnicos, humanos, formativos, etc. para conseguir que un producto se entregue correctamente. No tiene nada que ver con ser respetado con un autoritarismo medieval, sino con ganarte una cierta autoridad para que tus decisiones sean respetadas porque has demostrado tu experiencia y tus aciertos así como tu aceptación de los errores (sin colgarle a otros el muerto, cosa lamentablemente bastante común).

Hay muchos proyectos software que terminan con un éxito maravilloso gracias a la pericia de los desarrolladores del equipo en quienes un gestor incompetente ha delegado gran parte de sus responsabilidades; cuando esto ocurre, les recomiendo a estos desarrolladores que busquen otro jefe o incluso que cambien de compañía, ya que seguramente estarán mucho menos recompensados económicamente que su gestor, jefe, coordinador o lo que sea, injusto, pero esta situación se vive cada día y en todo tipo de compañías.

Del mismo modo que se busca un tipo de empresa para la que trabajar, ¿por qué no también buscar rodearte de un ambiente creativo con gente competente que te permita avanzar todavía más en tu desarrollo profesional? ¿Estás rodeado de gente a la que criticas y con la que tienes que trabajar, que consideras incompetentes y que no te aportan nada salvo algunos ji-ji y ja-ja en la hora del café? Pues toma nota, estás perdiendo el tiempo.

Si eres desarrollador y quieres gestionar proyectos software, busca trabajar con un buen gestor que te transmita su experiencia, lee libros al respecto y déjale claro de paso que estás preparado para asumir nuevas responsabilidades (pero ojo, no de palabra, sino con un trabajo de calidad en tu día a día).

Un gestor de proyectos aprende continuamente (el que crea que ya lo sabe todo estará fuera del mercado en unos años) y los desarrolladores con los que trabaja deben también ser capaces de aprender de él todo lo posible para el mejor desempeño de su profesión.

Si trabajamos como freelance casi todo lo anterior sigue siendo igualmente válido, ya que en ese caso seremos gestores de nuestro propio trabajo y al mismo tiempo seremos desarrolladores de un proyecto que también se tiene que hacer en orden y con calidad.

Este verano me pidieron que evaluara una sencilla tienda online para estimar el coste y esfuerzo necesarios para añadirle nuevas características (y corregir de paso algunos detalles que no funcionaban bien) y, para mi sorpresa, me encontré con algo que es habitual en nuestro sector: aplicaciones que están mal planteadas, mal hechas, escritas de cualquier forma, a pesar de que con ella el cliente final había facturado en el último año más de veinte mil euros en pedidos.

Es ya recurrente el siguiente ejemplo: cuando compramos un coche nos interesamos por muchos de sus acabados, prestaciones y, cómo no, detalles de su mecánica interna (fabricante del motor, etc); del mismo modo para la construcción de una casa se necesita la firma de un arquitecto colegiado (al menos en España) cuya función se supone que es la de supervisar todos los aspectos técnicos de la construcción.

Me pregunto entonces por qué para un proyecto software a casi ningún cliente se le ocurre preguntar o preocuparse por la calidad del proyecto que se le entrega, sin saber en realidad que según esa calidad, el coste de evolucionar o mejorar en el futuro la aplicación será asequible y razonable o desorbitado (cuando no se termina por tirar el sistema a la basura y realizar otro de nuevo desde cero).

De este modo, en muchísimos casos en nuestra profesión, para clientes de pequeño tamaño, medianos o grandes corporaciones, se entregan aplicaciones que en realidad son una manzana envenenada que explotará más adelante en cuanto el cliente necesite modificaciones o cambios, que es lo normal para casi cualquier tipo de software.

¿Compraríamos un coche que no se puede reparar o mantener? Absurdo.

Me planteo varias preguntas en relación a esto. ¿Cómo demostrarle a un cliente la calidad del software que se le entrega?

¿Cómo destacarnos de los competidores garantizando al cliente que nuestra solución va a ser más mantenible ante cambios? Este es un tema que da para mucho y es uno de esos asuntos recurrentes con los que nos encontramos día sí, día no.

¿Estaría el cliente dispuesto a un mayor coste si se le garantiza mejor calidad interna en lo que se le ofrece? ¿Tendrían sentido auditorías externas de calidad para poder dar un producto por terminado con su correcto certificado acreditado de calidad software? Vale, sí, sé que exiten auditorías así y que se suelen usar en grandes proyectos para grandes compañías pero eso es una gota en el océano.

En el caso que comentaba al principio, un simple vistazo a la estructura de la aplicación me hacía temer lo peor...

A continuación describo brevemente lo que más me llamó la atención:

  1. Nada de documentación. Cuando digo nada, es que ni un sencillo comentario en ningún fichero de código, muchísimo menos algún documento sobre las pautas de diseño seguidas, etc. De este modo, lo único que nos queda hacer es bucear entre la aplicación e ir viendo o suponiendo cómo está todo organizado. Del mismo modo, ninguna guía de despliegue que te diera pistas sobre cómo poner la aplicación en marcha en un entorno de desarrollo o explotación.
  2. Ni rastro de ningún tipo de pruebas. Yo diría que esto es lo peor, ya que de este modo el tiempo que se tarda en probar manualmente todo es extraordinariamente mayor y cuando tocas algo no tienes ninguna garatía de que no estás rompiendo nada (¿pero hay que explicar esto?)
  3. Sin diseño de la base de datos. Lo único que existía era un script larguísimo exportado desde phpMyAdmin...
  4. Ausencia de evidencias del uso control de versiones. Esto en sí mismo y para retomar una aplicación no es del todo imprescindible, pero ya el hecho de que no se usara una herramienta de control de versiones te da una idea de cómo se hizo la aplicación en su día.
  5. Múltiples sitios donde configurar las mismas contraseñas. Esta dispersión de contraseñas hard-coded no es que esté mal, es que es una característica de neófito absoluto, qué le vamos a hacer. ¿Hay que indicar que si tienes las mismas contraseñas o configuraciones en X sitios, cuando las cambies, vas a tener que perder mucho tiempo en modificarlas en todos y cada uno de esos sitios (si es que no se te olvida alguno y después tendrás que perder aún más tiempo depurando?
  6. Mala estructura de la solución. Cuando digo mala quiero decir que no se distinguía dónde estaba la parte de la interfaz de usuario, dónde el back-end y tampoco se intuía dónde podía estar la lógica de negocio. Todo estaba mezclado y disperso por aquí y por allá. Si es la primera vez que usamos esas tecnologías, entonces es normal que andemos un poco perdidos sobre la mejor forma de organizar las cosas; no obstante, basta buscar en GitHub por boilerplate para encontrar propuestas de esqueletos para cualquier tipo de proyecto.
  7. Layout de la interfaz de usuario con errores y hecho desde cero. Esto no es que esté mal, pero en un mundo multi-navegador con multitud de versiones por cada tipo de navegador, el hacer tú mismo este tipo de cosas puede llevar muchísimo tiempo en garantizar que al menos el layout funcione bien para los navegadores que más se usan. ¿No es mejor usar algo así como 960 Grid System o multitud de propuestas maduras para este problema?
  8. Extensos ficheros css y js sin minificar ni concatenar. Esto tampoco es que sea imprescindible, pero existiendo herramientas que te permiten reducir todos los ficheros CSS y de javascript a un único fichero .css y .js (este último además ofuscado), ¿por qué no usarlo?, así la aplicación gana algo más de velocidad en cada request, entre otras ventajas.
  9. Agujeros de seguridad como claves sin encriptar en base de datos y campos de texto cuyos contenidos no son filtrados para evitar ataques XSS. Ningún comentario.
  10. Partes de la aplicación en completo desuso. Tampoco es que esto esté del todo mal, pero si mantenemos código muerto y partes que no se usan, nuestra aplicación será más difícil de organizar y mantener: sólo debe existir aquello que la aplicación usa. Si tenemos miedo de perderlo, ¿para qué entonces tenemos la herramienta de control de versiones?

Esto es la punta del iceberg, ya que podría añadir que la aplicación no está en absoluto modularizada y ordenada (las clases de acceso a datos diseminadas, el front-end mezclado con el back-end), ausencia total de estilos a la hora de escribir el código (variables privadas escritas de distinta forma, por poner un ejemplo) y un largo etcétera.

Nada más lejos de mi intención criticar, en absoluto (no quiero acumular karma negativo...), pero me pregunto hasta qué punto degrada nuestra profesión entregar trabajos así que después van a entrar en explotación para un cliente para el que parte de su facturación dependerá de este sistema. 

No sé si es un consejo que vale para todo el mundo, pero cuando entrego un nuevo trabajo intento garantizarle al cliente que se ha hecho mucho esfuerzo para que la calidad de lo que se le entrega sea alta (además de cumplir correctamente con todos los requerimientos funcionales); otra cosa es que esa calidad interna sea valorada o no por el mismo cliente.

Quizá estamos pasando una época en la que el mismo concepto de éxito se está redefiniendo de una manera totalmente distinta. Hasta hace bien poco, se consideraba una persona de éxito aquella que económicamente ha conseguido reunir una gran fortuna o patrimonio (sin importar la forma), una empresa de éxito aquella que ha crecido con dos dígitos porcentuales de año en año (sin importar la satisfacción laboral de sus ejecutivos, empleados y clientes), una familia de éxito aquella que vive rodeada de comodidades y maravillosas vacaciones en hoteles con todo incluido (sin importar tampoco la falta de conexión entre sus miembros), por poner algunos ejemplos. Al mismo tiempo el downshifting laboral comienza a ser un fenómeno cada vez más común.

¿Y qué demonios tiene esto que ver con el desarrollo de software?

Como en cualquier otra actividad profesional proyectamos en ella muchos defectos y virtudes que heredamos de nuestra vida diaria, aunque la relación no la veamos directamente.

Recientemente El Libro Negro del Programador ha recibido un comentario bastante elogioso desde Amazon.com y que, con permiso de su autor (al que agradezco profundamente), copio y pego a continuación:

"Lectura indispensable para los que nos dedicamos a la programación porque trata temas esenciales en cuanto a la productividad, la eficiencia, la calidad del software y el manejo del tiempo. La gran ventaja de este libro es que no es un libro mas sobre teoría de la ingeniería de software, sino que el autor aporta la gran experiencia que tiene y acierta en la solución los problemas a los que nos enfrentamos los desarrolladores a la hora de afrontar proyectos de desarrollo, explica con detalle cuáles son las malas prácticas que llevan al fracaso de los proyectos y plantea soluciones efectivas. Un punto clave que platea el autor es la importancia de nuestra profesión en el contexto actual mostrando las ventajas de ser un buen profesional del desarrollo, estas ventajas las muestra presentando un panorama muy positivo con grandes expectativas en el entorno productivo."

Para mí que el éxito se tiende erróneamente a asociar más al efecto que a la causa que lo provoca y de ahí que cometamos recurrentemente el error de embarcarnos en un proyecto sólo por su remuneración económica (vale, vale, ya sé que la pasta es importante, pero ni mucho menos es lo único), o ser amable con alguien para conseguir algo de esa persona, o apuntarnos a un intenso programa de ejercicio para adelgazar esos kilos de más, etc.

La cosa no funciona así, en absoluto: primero hay que ser (pero qué místico me está quedando esto), después hay que hacer y como resultado de todo eso, viene el tener: ser - hacer - tener. Ese es el orden ineluctable y que no falla nunca. 

Sólo cuando un proyecto resulta de utilidad a otras personas redundará en éxito económico, sólo cuando alguien nos cae sinceramente bien y le tratamos con respeto esa amabilidad se volverá a nuestro favor y sólo cuando nos gusta y hacemos ejercicio con regularidad y como algo integrado en nuestra vida, entonces conseguiremos estar en forma de manera perdurable.

Se suele hablar de éxito sólo desde un punto de vista económico, pero eso es una visión demasiado estrecha y simplista de la realidad. Nada me satisface más que uno de mis trabajos, como El Libro Negro del Programador, sea considerado de utilidad para otras personas: si con este proyecto he conseguido mejorar la vida y perspectivas profesionales de algunas personas, si les he ayudado a mejorar un poco, aunque sólo haya sido un poco, sus trayectorias laborales, si les ha servido para no cometer alguno de los errores más típicos y recurrentes en software, sólo entonces, consideraré El Libro Negro del Programador como un trabajo de éxito, y sólo si esto es así será cuando algo me llegue en forma de royalties...

El comentario anterior me llena de satisfacción y ánimo por la sencilla razón de que me muestra que el libro resulta de utilidad: esta es en realidad la esencia de cualquier proyecto con el que queramos conseguir algo. Cualquier trabajo, del tipo que sea, enfila hacia el éxito si sabe identificar necesidades no cubiertas y si al final resulta de utilidad a un grupo de gente que estará dispuesta a pagar por él. Así de sencillo, pero al mismo tiempo tan difícil de tenerlo en cuenta en todas nuestras decisiones.

En software a veces se nos olvida que lo que hacemos, el código que escribrimos, las interfaces de usuario que diseñamos no las hacemos para nosotros mismos sino para el cliente final. También se nos olvida que debemos escribir código de forma que cualquier persona que retome el proyecto en el futuro lo pueda asumir sin tener que desentrañar una aplicación con un diseño críptico e imposible de entender.

Me temo que me encuentro con personas que alardean de trabajar para una gran compañía, de ámbito internacional, pero que al mismo tiempo se quejan de tener que viajar tan frecuentemente que no pueden estar todo el tiempo que les gustaría con sus familias. Quizá tienen un saldo bancario excelente, pero ¿qué tipo de éxito es aquel que nos impide lo esencial, como es el estar con nuestros hijos, a cambio de una remuneración alta? Desde fuera pueden ser vistas como personas de éxito, pero desde dentro la cosa será muy distinta. Es sólo un ejemplo de cómo ese mismo éxito tiene muchas caras, luces y sombras.

Las personas que llegan a nuestra profesión exclusivamente como salida laboral tienen pocas probabilidades de encontrar un hueco a largo plazo en esta actividad tan exigente; claro que es legítimo buscarte la vida lo mejor que uno pueda, pero esta exigencia que es consustancial a nuestra profesión sólo se puede superar si realmente te gusta.

Los mejores profesionales que conozco son aquellos que realmente disfrutan con lo que hacen, que adoran su trabajo y a veces lo confunden con su mejor hobby. Un síntoma inequívoco que nos indica si lo que hacemos nos apasiona es si llegamos a ese estado de flujo en el que el tiempo, sencillamente, deja de existir y el cansancio no es más quen una simple anécdota. Si este estado del que hablo te suena a chino, entonces es que nunca has estado tan inmerso en una tarea que no te ha importado nada más.

Sólo estas personas pueden aguantar los momentos de crisis, las tensiones que se producen cuando se acercan las fechas de entrega peligrosamente, porque saben que en el fondo, están esperando esa maravillosa sensación adictiva que es entregrar un buen trabajo e irte a casa con la sensación de que te mereces el dinero que cobras por él.

¿Utópico?, de ningún modo, conozco personas así y son las que al estar con ellas irradian energía de arriba abajo, que hablan de lo que hacen con un entusiamo visceral y que lo proyectan en todo lo que hacen. Eso sí que es para mí éxito, la enorme suerte de poder vivir de aquello que te apasiona y no trabajar para otros mercenariamente por una nómina. Ni que decir tiene que tenemos que vivir de algo, pero ¿qué sería del mundo si asumiéramos un concepto de éxito más en relación a la calidad de vida, bienestar y sosiego mental, satisfacción con lo que uno tiene y es, relaciones armoniosas, ausencia de estrés y, por supuesto, la satisfacción de aportar y dar por sí misma? Seguro que el PIB sería entonces muy distinto...

Reconozco que siempre he estado muy interesado en el desarrollo web y, de hecho, hice mis primeras aproximaciones a título personal allá por el 2006 hasta caer en los brazos del magnífico Drupal con el que comencé una start-up (que, como tantas, no terminó de cuajar). Aunque dirijo un grupo de desarrollo como responsabilidad principal en la compañía para la que trabajo, mantengo como uno de mis mantras eso de no desvincularme nunca de la fontanería y conceptos de bajo nivel del desarrollo de software. ¿Cómo si no se puede gestionar un proyecto software si no se conocen con total profundidad los building blocks que lo constituyen? Se puede dirigir, claro, pero entonces el riesgo de tomar malas deciciones, incurrir en desviaciones, etc. será mucho mayor. De esta forma, he seguido siempre de cerca ciertas tendencias, inciativas que han perdurado y otras que cayeron en desuso relacionadas con el mundo web, aún dedicándome casi siempre a realizar aplicaciones pesadas con tecnologías .NET, fundamentalmente.

Cuando decimos que la economía se está moviendo a lo digital, a veces no captamos las implicaciones enormes que tiene esto para un desarrollador profesional de software: significa que se están volcando recursos económicos de manera masiva a la implantación de proyectos empresariales y negocios en Internet y, por tanto, la demanda de buenos profesionales con expertise demostrable será cada vez mayor.

Quedan muy atrás aquellas webs de los noventa casi anecdóticas que apenas eran folletos publicitarios: ahora hablamos de una verdadera industria, desde hace años, que está cambiando el modo en que nos relacionamos y el modo en cómo la tecnología modifica hábitos sociales, como por ejemplo el concepto de economy sharing.

Hay mucho escrito sobre MEAN, de modo que me voy a centrar en las auténticas razones por las que para mí a un desarrollador que conozca bien este stack no le va a faltar trabajo en los próximos años.

Muy brevemente, ¿qué es el stack MEAN?, es un conjunto de tecnologías relacionadas que te ofrecen todo lo necesario para realizar una aplicación web moderna, escalable, testeable y, sobre todo, mantenible (aunque esto último dependerá de las buenas prácticas). MEAN viene de:

  • MongoDB, base de datos no relacional. El stack no te obliga, en absoluto, a usar MongoDB, de hecho, actualmente estoy implicado en un proyecto con MySQL + _EAN.
  • Express, middleware extraordinariamente sencillo y potente para la generación de aplicaciones web. Se aprende en una tarde, en serio...
  • AngularJS, aproximación declarativa al desarrollo de interfaces de usuario extaordinariamente potente. Te permite implementar MVC (o MVVC, depende de los gustos) en el lado del cliente web, de manera que la lógica de presentación, de negocio y las vistas con los modelos están desacopladas. Aquí está lo importante, al poder escribirlas desacopladas, se pueden desarrolar tests contra ellas!. Además, AngularJS es un proyecto de Google.
  • NodeJS, framework de servidor con un universo de módulos increíble y en expansión que te permite escribir en javascript aplicaciones de servidor siguiendo un modelo de programación por eventos. NodeJS, como framework, se puede usar para muchos escenarios: uno de ellos (y ni mucho menos el único, aunque se suele confundir) es el desarrollo de aplicaciones web.

Juntando todas las piezas obtienes un stack muy maduro y coherente para escribir aplicaciones web modernas, escalables y testeables; para mí, de los building blocks que constituyen el corazón de este stack, los más relevantes son los middlewares de Express a través del módulo Connect, las directivas de AngularJS y su implementación de MVC, que todo puede ser testeado con Mocha y Karma y, sobre todo, el modelo de desarrollo de NodeJS basado en eventos que te permite olvidarte de problemas de concurrencia y sincronización entre operaciones asíncronas.

Hace varios años, cada vez que volvía a retomar algún proyecto web, me chocaban algunas cosas que no me gustaban en absoluto:

  • La manipulación directa y horrorosa del DOM (estamos hablando de hace bastantes años), con todos lo problemas multinavegador.
  • Viniendo de un framework pesado como .NET en el que C# daba coherencia a una solución final (front-end, back-end y acceso a repositorios de datos o servicios), me resultaba frustrante tener que usar ciertas tecnologías de cliente y ciertas tecnologías de servidor (javascript, css, html en el lado cliente y php, por ejemplo, en el otro lado del servidor). Esto encarecía enormemente la mantenibilidad de un mismo proyecto.

Con el tiempo fueron surgiendo mejores alternativas de estandarización y maravillosas librerías como jQuery junto con sus widgets, Modernizr, preprocesadores para CSS como Less, Sass y Stylus, etc. que liberaban al desarrollador de los problemas fundamentales y le permitían escribir código de manera más legible, rápida y mantenible. No obstante, existía aún una clara diferencia entre desarrollo web para front-end y el desarrollo del back-end en el servidor, y, de hecho, la mayoría de las aplicaciones web se siguen desarrollando de esa manera.

Hasta que hace unos años leí un artículo sobre un proyecto emergente llamado NodeJS que me dejó confuso: sabía que ahí se había llegado a algo importante aunque ese día no sabía exactamente por qué. Con el tiempo fueron encajando las piezas aunque reconozco que el día que conocí NodeJS sufrí un momento de epifanía..., aún sin saber para qué podía servir.

No hay tecnologías buenas ni malas (resulta hasta infantil las interminables discusiones que si .NET versus Java, que si Oracle versus Sql Server, en fin...), todo depende de la naturaleza del proyecto a realizar y de la solvencia técnica de quien lo implemente (sobre todo lo segundo): un desarrollador especializado en spaguetti software no va a usar bien ningún framework que se ponga por delante, el usar un maravilloso motor de base de datos sin conocerlo suficientemente llevará al traste a una aplicación con consultas mal escritas, etc. A veces se nos olvida que cualquier tecnología o stack de tecnologías tiene su pros y sus contras, y que la mayoría de las veces defenestramos las que no nos gustan por ignorancia de las mismas.

Desde hace un tiempo el stack MEAN para mí ha alcanzado la madurez, seguimiento de mercado y comunidad suficiente como para tomarlo muy pero que muy en serio, es, de hecho, un conjunto de tecnologías emergentes de las que se hablará (y utilizará) muchísimo en los próximos años, de eso no tengo ninguna duda.

Pero, ¿qué aporta este stack?, en mi opinión hay que destacar lo siguiente:

  • Te permite escribir una aplicación web de principio a fin usando javascript como único lenguaje, si bien las librerías que se usan en el front-end son distintas, lógicamente, de las que se usan en el lado del back-end con NodeJS.
  • AngularJS, bien usado, te libera de la necesidad de manipular directamente el DOM del navegador, permitiéndote escribir de manera declarativa gran parte de la funcionalidad de la interfaz de usuario, pero, sobre todo, desacoplando la lógica del cliente siguiendo el patrón modelo-vista-controlador y por ello permitiéndote escribir tests.
  • El stack te permite poder escribir fácilamente aplicaciones SPA (single page application) en las que el cliente web mantiene gran parte de la lógica de aplicación y el lado del servidor implementa la API necesaria para darle soporte, ahorrando así continuos requests http completos de todo el documento html y sus artefactos software.
  • Dispones de un alto grado de control de todas las cosas que son de más bajo nivel (gestión de cookies, cabeceras, routing, etc.) pero al mismo tiempo están suficientemente abstraídas para que su uso sea trivial.
  • Existen frameworks de tests elegantes tanto para el front-end como para el back-end.
  • El despliegue de la aplicación es sencillo.
  • Siguiendo las buenas prácticas, es multiplataforma.
  • ... y un larguísimo etcétera.

Inconvenientes tiene, claro que sí, pero como cualquier otro stack hay que saber si es conveniente o no para la naturaleza de la aplicación que quieres realizar. La curva de aprendizaje no podemos decir que sea rápida, ya que por poner un ejemplo, AngularJS te obliga a pensar a resolver el cliente web de otra manera y el modelo asíncrono de NodeJS también te obliga a enfocar el lado del servidor con una aproximación mental distinta.

Cuando nos enfrentamos a un nuevo tipo de proyecto en el que vamos a usar tecnologías que no dominamos del todo o es la primera vez que las usamos en un proyecto profesional, suele ser un error que tu primer proyecto con esas tecnologías sea precisamente el que vas a entregar a un cliente; este, sin saberlo, va a ser un conejillo de indias del proveedor que decide con acierto o no los mejores frameworks y librerías para ese tipo de proyecto, si es que esta evaluación se ha llegado a hacer.

Lo peor se presenta cuando quien decide usar un stack de tecnologías en concreto lo hace no porque se ajuste a ese proyecto en particular, objetivamente, dada su naturaleza, sino por sencillo capricho y porque se presenta así una oportunidad maravillosa de aprender en el trabajo sobre aquello que fuera de él no se tiene tiempo... Esto lo he visto varias veces y es una tentación demasiado grande como para no hablar de ello; igualmente, quien cae en esa tentación se podrá considerar desarrollador de software, pero desde luego no profesional. En ocasiones, los desarrolladores de software parece que juegan en su trabajo en lugar de buscar realizarlo con la mayor profesionalidad posible.

Lo importante es tener la capacidad de seleccionar correctamente las mejores tecnologías a emplear en un proyecto dado su naturaleza y sus requerimientos. En esto tenemos que ser totalmente asépticos y no dejarnos llevar por modas o gustos particulares.

No hace mucho, he visto cómo un cliente ha tenido que tirar a la basura (literalmente) un front-end de comunicaciones de dispositivos realizado inicialmente con un CMS bastante popular y profesional (que, por cierto, a mí me gusta mucho y con el que está hecha esta web...), pero para nada adecuado para ese proyecto. Intuyo que tras esa decisión hubo o bien un gusto personal del desarrollor que tomó esa elección (sin evaluar riesgos futuros o sin plantearse la idedoneidad para ese proyecto) o bien forzar a usar ese CMS por la indolencia de no querer molestarse en aprender tecnologías más adecuadas. Para esta selección se requiere bastante experiencia y haber tocado un poco de esto y un poco de lo otro para conocer lo suficiente para tomar una elección, sin entrar en el diletantismo tecnológico que consistuye uno de los capítulos de El Libro Negro del Programador.

Si estamos en la situación en la que se ha elegido un stack de librerías / tecnologías que no conocemos en profundidad y que debemos usar en un nuevo proyecto, podemos caer en el error de comenzar este sin más. Si lo hacemos así, todos los errores que podamos comenter por ser neófitos en esas tecnologías los cometeremos en ¡el proyecto de un cliente!.

Es fácil no conocer las buenas prácticas asociadas a ciertas librerías o frameworks cuando no los hemos usado antes suficientemente, no conocer los tips & tricks y estar lejos de saber resolver los escenarios más elementales con esas nuevas tecnologías. Eso creará una deuda técnica en el proyecto que nos pasará factura con total seguridad.

¿Y entonces?

La solución está en que antes de comenzar a escribir código de producción, dediquemos un tiempo a realizar un prototipo que resuelva o nos permita aprender los elementos más importantes y críticos del proyecto. Una vez resueltos estos elementos, los sabremos estructurar e integrar mejor en el proyecto final que se entregará al cliente.

Al final vamos aprendiendo con muchísima prueba y error, por esta razón no podemos cometer errores de novato en un proyecto final para un cliente: antes debemos conocer suficientemente bien las tecnologías que se han decidido usar y, para ello, nada mejor que implementar un sencillo prototipo que nos aclare las dudas fundamentales.

Igualmente, la lectura de un grupo de libros sobre esas tecnologías resulta fundamental: leer un libro es aprender de la experiencia de otros, nada peor que aprender algo nuevo googleando y foreando resolviendo problemas puntuales, lo cual nos impide entender en su conjunto un framework o librería que tiene una filosofía de diseño particular que hay que comprender para usarla correctamente.

El tiempo dedicado tanto a esta formación como a prototipar la solución no es un gasto, sino una auténtica inversión, ya que así la solución final para el cliente se hará más rápido puesto que conocemos lo suficiente las tecnologías que se emplean y, además, si  invertimos ese tiempo en formarnos con libros y recursos de calidad, aumentaremos en varios niveles nuestro acervo profesional de cara al futuro.

 

No hace mucho he leído en un libro sobre AngularJS la siguiente sendencia, aplastante e ilustrativa:

"Software development is hard. As developers, we need to juggle customer requirements and pressure of deadlines, work effectively with other team members, and all this while being proficient with multitude of software development tools and programing languages. As the complexity of software rises so is the number of bugs. We are all human and we will make mistakes, tons of them. Lower-level, programming errors are only one type of defect that we need to constantly fight. Installation, configuration and integration issues will also plague any non-trivial project."

(Mastering Web Application Development with AngularJS)

No lo habría podido expresar mejor: durante el desarrollo de cualquier proyecto, una de las tareas a las que nos dedicamos es a desarrollar nuevo código de producción, pero esta es una tarea más; al mismo tiempo se realizan muchas otras tareas relacionadas con el proyecto pero igualmente importantes. No obstante, en ocasiones se trivializa la importancia de esas otras tareas pensando que poco tienen que ver con el proyecto y que en realidad lastran el escribir nuevo código; porque lo divertido, lo que más nos gusta a los desarrolladores de software es "escribir código", ¿no es así?

Eso podría pensar una mente ingenua recién llegada a un sector en el que mirar hacia atrás varios años es ver la prehistoria por una renovación continua de nuevas tecnologías, flujos de trabajo y, por qué no, incluso nuevos tipos de proyecto.

Todas esas otras tareas alrededor del código son las que hacen que éste se escriba con calidad y que se trabaje de manera eficiente y productiva. Si esto no lo hemos asumido, entonces estamos aún varios pasos atrás de trabajar realmente como profesionales. La calidad de un proyecto no sólo se mide porque el cliente obtenga un producto software de utilidad, también por cómo el mismo proyecto software pueda evolucionar, ser mantenido y evolucionado, y, además, en mi opinión una cuestión que no siempre es evidente, que los desarrolladores puedan trabajar en él de manera eficiente, productiva y con satisfacción.

De ninguna manera podemos pasar a codificar como siguiente paso una vez que tenemos claro los requisitos. Cuando comenzamos un nuevo proyecto, antes de teclear la primera línea de código, tenemos que definir claramente, entre otras cosas:

  • Las tecnologías más apropiadas a usar y la fricción entre ellas. Como apuntaba en un post anterior, en el desarrollo de aplicaciones web modernas, por poner un ejemplo, nos podemos encontrar con una explosión de librerías y frameworks que continuamente te hacen dudar si estás eligiendo la mejor opción.
  • Definir el flujo de trabajo (workflow) de los desarrolladores y ciclo de vida.
  • Detectar todo aquello que se pueda automatizar (compilaciones automáticas, pruebas de validación finales, etc). Esto es un elemento de apalancamiento impresionante y no siempre se tiene en cuenta: cualquier esfuerzo dedicado al principio en este punto, nos ahorrará ese esfuerzo multiplicado a lo largo de la vida del proyecto. Como mantra, yo siempre me digo que "todo aquello que hacemos manualmente en el proyecto varias veces al día se debe intentar automatizar". Esto hace posible que una vez que estemos trabajando en el proyecto nos dediquemos básicamente a implementar historias de usuario, la funcionalidad que se nos ha pedido.
  • Definir también cuál va a ser la estructura del proyecto: en qué carpeta va a ir el código, dónde y cómo se van a generar las pruebas, dónde se van a incluir los assets del proyecto, etc. Esta definición evitará que los miembros del equipo vayan incluyedo todos estos artefactos donde mejor les parezcan y sin coherencia.
  • Desde un primer momento, definir el despliegue del proyecto en producción para así anticipar desde la primera entrega problemas que de otro modo surgirían al final.

Todo esto, digo, se tiene que definir y poner en práctica antes de teclear la primera línea de código. La tentación de pasar directamente a desarrollar para tener algo que mostrar cuanto antes es en engaño que nos autoinfligimos: de tener todo lo anterior bien claro y definido, dependerá que ahorremos muchísimo esfuerzo en el futuro y, por tanto, redundará en la calidad del producto que generemos.

De aquí se pueden crear algunas reglas sencillas que debemos seguir siempre, como aquella que repito tal que no se realiza ninguna actividad si esta no ha sido previamente planificada, por ejemplo:

  • No se implementa nada nuevo si no ha sido incluido en la fase actual de trabajo con los tiempos de desarrollo estimados.
  • No doy por finalizado nada si no he creado las pruebas necesarias para demostrar (hoy, mañana, la semana que viene, etc.) que funciona.
  • No genero ningún nuevo artefacto software si antes no se ha establecido dónde y cómo tiene que ser generado.
  • ...

Estas reglas, sencillas en esencia, suponen la base por la que un equipo de desarrollo trabajará de manera productiva y ordenada.

Con la irrupción de los smartphones y tablets de los últimos años y el paso acelerado de parte de la economía tangible a la economía digital, el desarrollo web se ha visto tremendamente fragmentado, sectorizado y disperso en un conjunto cada vez mayor de tecnologías heterogéneas. No es raro que cualquiera que se acerque por primera vez a la programación web sienta cierto vértigo al decidir qué herramientas usar, qué tecnologías emplear. Aquí hay que hacer un auto de fe que en ocasiones te lleva a estudiar a fondo los frameworks más de moda con el riesgo que esto supone.

Muy lejos queda cuando alguien era capaz de definirse como maquetador web o web master (sólo pensar en estos conceptos trasnochados me chirrían los oídos), aunque no es raro que aún se incluyan esos términos en algunos currículums... El panorama ha cambiado radicalmente y ha evolucionado tanto que la industria ahora bendice todo lo que suene a estándar o tecnología no propietaria.

Hoy es tal la cantidad de opciones disponibles para comenzar un nuevo proyecto web que es tremendamente difícil acertar en las más adecuadas dada las características del proyecto. Algunas preguntas recurrentes suelen ser:

  • ¿Me baso en un CMS flexible como Drupal?
  • ¿Lo hago desde cero (...)?
  • ¿Diseño mobile first o desktop first?
  • ¿Evolucionará el proyecto mucho, poco o nada en el futuro?

... y esto si no caemos en el error que querer usar porque sí las tecnologías que más conocemos y que más cómodas nos resultan (por eso de evitar salir de nuestra zona de confort).

Ya el concepto de programador web tiene poco contenido, al menos a mí me dice más bien poco: ¿especialista en front-end, en back-end, en despliegue de infraestructura, en diseño, en usabilidad, SEO, etc.? Me temo que no todo el mundo puede ser excelente en todas esas áreas, de ahí la fragmentación y la realidad ineluctable para la que un proyecto más o menos extenso tenga que contar con perfiles diferenciados.

Desde hace mucho hemos pasado del concepto de página web a aplicación web para la que su desarrollo requiere de habilidades y roles bien distintos:

  • Diseño y usabilidad (user experience o UX). El éxito de cualquier web, sobre todo si se basa en la atracción de tráfico para generación de contenidos o ventas va a depender directamente de un buen diseño y una magnífica usabilidad. Además, hacer un diseño responsive puede ser todo un reto y un trabajo adicional importante a considerar.
  • Front-end, es decir, todo aquello que muestra al usuario final el contenido de la web y le permite interactuar con ella.
  • Back-end: todo lo que se cuece por detrás y que da soporte al front-end: APIs basadas en web services o servicios REST, acceso a base de datos, etc.
  • Si existe una base de datos, su buen diseño y mantenimiento es una tarea relevante.

Necesario pero no suficiente... una aplicación web tiene que ser desplegada en algún entorno e infraestructura IT: ¿servidores web Apache, Nginx, LightTpd, IIS, en la nube con Amazon EC2 o Azure de Microsoft? Esos entornos, lógicamente, tienen que estar bien configurados y correctamente mantenidos y todos son un mundo en sí mismos.

Una vez desplegada la web y en funcionamiento de cara a los usuarios, el trabajo no queda ahí: hay que medir la web tanto en el éxito de su funcionamiento como en el uso que hacen de ella los propios usuarios; es ahí donde interviene la analítica web. Si además al sitio no llega nadie (que vendría a ser algo así como pintar un cuadro maravilloso pero que nadie ve) habría que implantar tácticas SEO y SEM. Es más, esas tácticas se implantan no al final de desarrollo sino también durante el mismo: forman parte del mismo desarrollo del proyecto.

Lo que quiero destacar aquí es el carácter heterogéneo y poliédrico del desarrollo, evolución y mantenimiento de una aplicacion web que queda muy lejos del concepto simplista de quien se autodenomina programador web; así las cosas, mejor definirte en tu propio currículum como experto en ciertas áreas tales como:

  • Experto en front-end basado en Foundation, Bootstrap, etc.
  • Desarrollador de back-ends basados en node.js, APIs REST, ASP.NET Web API, etc.
  • Diseñador especializado en comercio digital, usabilidad y RWD (responsive web design)
  • Administrador de sistemas web basados en tecnologías LAMP.
  • Conocimientos de diseño web y UX.

Anótate esto y ahora mismo ve a cambiar tu currículum indicando un perfil más explícito como los anteriores.

Y, para colmo, ¿qué hay de todos los aspectos sobre seguridad?. La seguridad afecta transversalmente a varios de los roles que hemos identificado anteriormente, de modo que a la lista anterior añadiríamos:

  • Experto / auditor en seguridad web.

De este modo cada vez que me llega un currículum con una línea en donde pone desarrollador web, pues..., la verdad, no sé exactamente qué pensar.

No es sólo cuestión de en qué rol te identificas más o menos, en cual tienes más o menos experiencia, es que, además, para cada uno de ellos las herramientas, tecnologías, frameworks, etc. que existen son extraordinariamente amplias, por lo que podemos caer en el riesgo de especializanos en algún framework que hoy día puede ser muy popular pero del que nadie hable dentro de un tiempo.

Si trabajas en el desarrollo web y tus habilidades, herramientas y tecnologías que conoces son las mismas que hace tres años, aún no te han dicho que vives en la prehistoria y toca reciclarse, además profundamente.

La miríada de conocimientos, librerías y frameworks disponibles para un desarrollador de front-ends, por poner un ejemplo, son tan extensas que te hace dudar realmente de lo que sabes o dejas de saber: Foundation de Zurb, Bootstrap, Semantic UI, Gumby Framework, Javascript (esto es para despistados), CSS3, preprocesadores como Less y Sass, Blueprint CSS y un larguísimo etcétera aparte de pequeñas librerías imprescindibles como jQuery, Modernizr, HTML5Shiv, Respond...

Que haya tantas opciones, algunas excluyentes y otras complementarias en el mismo proyecto es en mi opinión extraordinariamente bueno, ya que así podemos afinar mucho sobre qué usar según las características del proyecto a realizar; sin embargo, tantas opciones pueden tener un lado muy perverso:

  • ¿Tendrán continuidad las librerías / frameworks que elijamos?
  • Si evolucionan, que sin duda lo harán, habrá que tener en cuenta el coste de adaptar y migrar nuestras soluciones ya en producción a las nuevas releases, si es que no queremos que llegue el momento de tener que mantener proyecto con librerías obsoletas dentro de algunos años.
  • Sin duda, si elegimos ciertas librerías nuevas para nosotros, su curva de aprendizaje supondrán un coste a añadir en el desarrollo del proyecto.

Este es un aspecto del desarrollo de software que comento prolijamente en El Libro Negro del Programador: la línea sutil que separa la elección de un buen conjunto de tecnologías y su evolución futura sin comprometer los proyectos cuando estén el produccion.

El desarrollo web es hoy día más poliédrico que nunca, más diverso que hace tan solo dos años y, precisamente por ello, con más opciones de desarrollo profesional que antes. Si te consideras un programador web activo, muy activo, pues enhorabuena, ¡no te vas a aburrir!

¿Somos los mejores profesionales que podríamos llegar a ser?

¿Aportamos valor realmente a la compañía para la que trabajamos o a los clientes que nos pagan los honorarios? ¿o nos limitamos a hacer lo que nos dicen y nada más y no sabemos tomar la iniciativa en ningún asunto?

Se usa a menudo la expresión aportar valor pero en la mayoría de las ocasiones sólo queda como un simple titular de promoción interna en los departamentos de recursos humanos. Queda muy bien, pero realmente no se cambia absolutamente nada para que exista una cultura corporativa que promueva el valor, el talento y la proactividad. Veo demasiada gente hablando de proactividad pero actuando muy poco proactivamente: decimos una cosa pero después hacemos otra totalmente distinta. A mí esto me suena al principo de la locura.

No sabremos aportar valor en nuestro entorno si no invertimos en nosotros mismos. Es, de hecho, la mejor inversión que podemos hacer.

Desde hace unos años participo en cierta medida en asuntos comerciales además de mi dedicación casi completa a dirigir un equipo de desarrollo, involucrándome, cómo no, en todo tipo de tareas técnicas, decisiones de diseño y arquitectura, toma de feedback de clientes, etc.

En este tiempo me ha llamado mucho la atención cómo bastantes clientes pontenciales de los productos que comercializamos se interesan por conocer el motor de base de datos que usa nuestro software. Los hay quienes le dan todas las bendiciones a SQL Server, otros que no cambiarían Oracle por SQL Server y unos pocos que nos han preguntado si el sistema podría funcionar con Cassandra (...). Nada que objetar, salvo su percepción completamente errónea de que el producto va a ser rápido y eficiente o lento y poco escalable según la base de datos que use, nada más.

Esta suposición, entendible para cierto perfil no técnico, la he visto también en otro tipo de perfiles muy técnicos y entendidos en software, para mi asombro.

La escalabilidad de un producto software no depende necesariamente de la base de datos que use, ni mucho menos: ésta es un elemento más de la larga lista de características que se le deben exigir a un producto software escalable.

No sólo he tenido que sufrir este tipo de polémicas en el eterno debate que si SQL Server  / Oracle, sino que además, todo lo que huela ahora mismo a volúmenes grandes de información rápidamente se asocia a la necesidad de una solución big data con Hadoop o MongoDB, confundiendo necesidades de almacenamiento con necesidades de análisis y procesamiento de la información.

Pero, ¿qué entendemos por escalabilidad? Esto va a depender el tipo de productos del que estemos hablando: para un portal web es sin duda el soportar un número alto de usuarios simultáneos, para una aplicación de análisis de datos, el poder captar y procesar cierto volumen de información; para un sistema de gestión de dispositivos físicos, como contadores digitales, por citar algo más ligado a mi actividad, no es lo mismo gestionar mil que cien mil dispostivos en un mismo sistema, con cinco o con cien operadores simultáneos.

Si un producto software usa una base de datos, de cualquier tipo que sea esta (relacional, no-sql, documental, etc), ésta por sí misma no va determinar el rendimiento del producto.

Esto que parece una perogrullada lo he tenido que explicar más de una vez a personas que se dedican a desarrollar software...

¿Qué determina un buen uso de una base de datos?

Este es un tema extraordinariamente amplio, pero para dar una idea de que el buen uso de una base de datos no es del todo trivial, podemos decir que no puede haber deficiencias en el diseño, sin redundancias innecesarias, las consultas a la base de datos deben ser sencillas y eficientes, se debe minimizar el número de consultas, cada consulta debe traerse la información estrictamente necesaria, las transacciones se deben dejar para las operaciones imprescindibles, debe hacerse un estudio concienzudo de los índices necesarios según la naturaleza de las consultas a realizar, según los casos habría que optar por las estructuras eficientes que ofreza el mismo gestor de bases de datos (particionado horizontal y vertical, por ejemplo), no mezclar una base de datos pensada para almacenamiento histórico con la base de datos de trabajo, dejar, si se puede según la idiosincrasia del producto, los procesamientos masivos de información para momentos que no interfieran en las ventanas de operación de los usurios clientes, y un largo etcétera .

Si este tipo de cosas no están bien resueltas, de nada nos servirá el mejor motor de base de datos.

En mi experiencia he visto claramente cómo la forma de almacenar la información determina lo sencillo o complejo que puede ser gestionarla por el software cliente de alto nivel. En ocasiones no falla cómo accedemos a la información, sino cómo esta información se encuentra almacenada en el repositorio de datos.

La forma en que necesitamos la información y cómo ésta se encuentra almacenada van de la mano.

Podemos incidir y hacer un buen trabajo a ese nivel mejorando el modo con el que nuestra aplicación accede a la base de datos, pero me temo que no queda la cosa resuelta del todo.

¿Qué ocurre con la arquitectura del propio sistema?

En cierto sentido, esta arquitectura va emergiendo a medida que intentamos que admita más y más dispositivos, usuarios o las entidades que representen la escalabilidad para nuestro producto.

Sin embargo, cuando hablamos de sistemas con grandes volumenes de procesamiento de información, tareas, procesos, etc. la arquitectura del sistema software es fundamental. Aquí ya hablamos de desarrollar software a otro nivel, con otro tipo de estrategias de diseño y desacoplamiento entre subsistemas para que cada uno haga su tarea de manera muy eficiente.

No hay estrategias generales que resuelvan cada caso concreto, pero sí buenas prácticas arquitecturales.

El poder distribuir estos subsistemas entre servidores distintos es todo un reto también de diseño para que todas las instancias puedan realizar su trabajo concurrentemente balanceando el trabajo, tanto si nos apoyamos en terceros sistemas para este propósito como si no.

Una aplicación que funciona bien para diez usuarios concurrentes no tiene nada que ver en diseño, arquitectura y diseño de repositorios de datos para la misma aplicación que tenga que dar servicio a 10k usuarios, por poner un ejemplo. La arquitectura no tendrá nada que ver, el diseño general y los microdiseños serán muy diferentes de un sistema a otro y el diseño y uso de la base de datos también serán extraordinariamente distintos.

La cuestión es que pocas veces comenzamos a desarrollar un nuevo producto sabiendo a ciencia cierta lo escalable que tiene que llegar a ser y en qué momento de su tiempo de vida deberá admitir más usuarios, dispositivos, etc. Hace falta mucha experiencia para prever esta arquitectura y los diseños adecuados. ¿Y entonces?

No existen soluciones mágicas para casi nada, pero lo que sí puedo asegurar es que si se comienza haciendo diseños limpios, con mucho esfuerzo en generar código desacoplado y de calidad, con una batería de pruebas suficientemente amplia, exhaustiva y mantenible, si nos esforzamos en cada fase del desarrollo del producto en identificar qué partes presentan cuellos de botella mediante análisis de rendimiento, etc. podremos tener un sistema para el que poder escalarlo no se convierta en algo dramático.

En ciertos sistemas complejos y más o menos grandes, todo, absolutamente todo cuenta: una iteración simple entre los elementos de una lista parece algo inocuo, pero cuando se ejecuta en un servidor cientos de miles de veces en un día, puede presentar un problema de rendimiento cuyo efecto se acumula desastrosamente a otros, presentando finalmente un problema global de rendimiento. Los detalles sí que importan.

Escribir código que funcione es nuestro trabajo, también es escribirlo de manera que funcione y que sea lo más limpio y simple posible, pero también que esa eficiente, lo que ya no es tan trivial en algunas ocasiones.

De hecho, existen libros dedicados a este asunto, como uno al que recurro habitualmente: Pro .NET Performance, por poner un ejemplo.

Otro recurso que uso confrecuencia (ligado a las tecnologías que más uso), es Improving :NET Application Performance And Scalability.

Por último, nada peor que encontrar problemas de rendimiento cuando el producto ya está en producción, si eso ocurre es que no se ha hecho un trabajo del todo bueno probando el sistema con anterioridad. No sólo hay que realizar tests unitarios, de validación e integración, también de rendimiento.

Así las cosas, cada vez que un cliente potencial con el que seguramente tenga media hora sólo para hablar, me pregunta qué base de datos usa el sistema, comprenderéis lo complicado que a veces resulta defender una respuesta cuando el cliente está más predispuesto hacia otro tipo de gestor de bases de datos que la que usamos.

Quizá nos han educado para buscar un empleo del que vivir, trabajar en algo con lo que ganarnos la vida y pagar las facturas a final de mes. Quizá, digo, no pusieron durante nuestra educación el énfasis necesario para que siempre busquemos trabajar en algo que no sólo nos guste, sino que nos apasione. Otra cosa distinta es que eso mismo lo busquemos como empleado o como empleador, aunque lo que aquí quiero recalcar es que la excelencia, la calidad, siempre surge cuando amamos lo que hacemos con una intensidad superior al resto de nuestras obligaciones.

No existe ningún trabajo en el que todas las tareas que tienes que realizar sean siempre gratas; para conseguir un objetivo final, un proyecto con resultados, hay que hacer muchas cosas diferentes, unas nos pueden gustar más, otras menos, pero si cuando terminamos el proyecto, dando paso a una nueva fase en él o comenzando otro completamente nuevo, no sentimos cierta satisfacción, orgullo personal o una sencilla alegría por haber terminado algo con calidad y lo mejor posible dadas las circunstancias, entonces es que no estamos dedicando nuestra vida laboral a lo que realmente nos apasiona.

En software esto tiene un impacto enorme, aunque no siempre nos damos cuenta de las consecuencias desastrosas que esto tiene para la ejecución con éxito de un proyecto.

De acuerdo, hay quienes son capaces de dedicar ocho o más horas a una actividad que ni les va ni les viene, lo cual no deja de ser una virtud, necesaria además en aquellos países donde la crisis financiera todavía tiene un impacto grande. No obstante, quienes nos planteamos nuestra carrera laboral como algo ascendente, con pasos positivos y progresivos hacia el éxito, lo que sea que cada uno entienda por éxito, no podríamos trabajar en algo por lo que realmente no sentimos pasión.

Nunca vas a ser bueno, un profesional altamente cualificado, si has elegido hacer algo que no te llena, que no te gusta. Es así de sencillo pero así de contundente.

Del mismo modo, en una profesión donde la excelencia tiene una relación tan directa en la vida de los productos software que construimos, esta característica de los desarrolladores es más relevante que en cualquier otra profesión.

Me gusta mi profesión, a veces tan poliédrica, me gusta realizar productos que le resulta a un usuario final de enorme utilidad. Hay ocasiones en las que un sencillo pero elegante refactoring que hago y que mejora de algún modo la calidad del código que escribo, me hace sentir muy bien.

Igualmente me siento bien cuando me resulta fácil detectar cualquier problema en la instalación de un cliente donde tenemos desplegados algunos de nuestros productos (se ha hecho el suficiente esfuerzo para que el software se pueda depurar), cuando nos plantean una nueva necesidad y vemos que perfectamente se puede encajar en las capacidades de integración del producto, cuando un cliente te felicita porque le resulta fácil utilizar la interfaz de usuario sin recurrir a la guía de usuario (interfaces amigables) o cuando te felicita también porque lo que antes tardaba en hacer varias horas, ahora lo puede realizar a golpe de clic ahorrando costes a su compañía (valor para el cliente final), y un largo etcétera.

Para conseguir eso, hacen falta muchísimas horas de trabajo, disciplina, perseverancia en la creación de pruebas unitarias y de integración, refactorización continua de código y de diseños en cada nueva funcionalidad, clase, librería, etc. implementada y todo eso, desde luego, no se podría hacer si no te has vuelto adicto a ese momento mágico en que etiquetas una nueva versión de tu producto o creas un nuevo branch sabiendo que la versión que cierras en ese momento está bien conseguida, tanto en funcionalidad como en calidad interna de código. Si a esto lo llamamos excelencia, entonces no puedes llegar a ella si pasas ocho horas o más al día trabajando esperando que te ingresen una nómina a final de mes.

Uno de estos momentos, que yo llamo de epifanía, fue cuando colgué mi primera web allá por el 2008 (bueno, no es que ahora esté realmente orgulloso de ese trabajo, pero esa era mi primera incursión en entornos web después de años dedicado a aplicaciones y entornos de backend muy escalables y optimizados).

Una persona que no encaja en lo que hace y en lo que pasa muchas horas de su vida, necesariamente no se va a esforzar por realizar el mejor trabajo posible: la pregunta que los desarrolladores de software profesionales se deben hacer cuando terminan una tarea, es ¿puedo mejorar esto en algo?, ¿puedo abstraer de aquí algo para mejorar el diseño de la solución?, ¿podría simplificarlo aún más?.

Un desarrollador puede terminar su trabajo y ya está, un desarrollador bueno se plantea algunas o todas esas preguntas de vez en cuando o puntualmente, pero un desarrollador excelente se hace esas preguntas continuamente.

Como responsable de grupo de trabajo, una de mis funciones es crear un equipo con personas que se sienten a gusto haciendo lo que hacen, que les guste realmente la mayor parte de las tareas de desarrollo que desempeñan, pero, sobre todo, que se sienten felices cuando se termina algo con una calidad magnífica.

No podemos innovar en áreas de trabajo que no nos gustan del mismo modo que no podemos ser lo más productivos posibles en aquellos trabajos que odiamos.

La primera vez que leí sobre este aspecto del desarrollo de software fue en The Passionate Programmer, de Chad Fowler, uno de los libros que descubrí hace años y que me convencieron de que programar era mucho más que escribir líneas de código.

Sólo podemos programar bien si realmente nos gusta este trabajo y esta profesión tan exigentes.

Esto es exactamente de lo que habla Ken Robinson en el TED en la charla antológica y su libro El Elemento, de cómo la pasión por lo que uno hace lo cambia todo:

https://www.ted.com/talks/ken_robinson_says_schools_kill_creativity

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