Rafa G. Blanes Blog

Hace unos años hice un ejercicio muy sencillo que recomiendo a todo el mundo que haga en algún momento del año: era viernes y anoté todas las llamadas telefónicas que había recibido durante la semana, tanto al fijo como al móvil.

Después fui analizando una a una (al menos aquellas de las que me acordaba) descubriendo algo que me hizo pensar bastante:

• La mayoría de las llamadas me interrumpieron en algo que estaba haciendo en ese momento muy concentrado.
• Muchas de ellas no me aportaron nada para resolver alguna tarea bajo mi responsabilidad, sino que me reclamaban para resolver las tareas bajo responsabilidad de otros.
• Otro grupo de ellas se podían haber sustituido con un sencillo correo electrónico que yo habría elegido leer en el momento mas adeacuado en el mismo día.
• Solo unas pocas eran verdaderamente importantes (para mí).
• Ninguna era absolutamente trascendente y urgente para que tuviera que atenderla en ese preciso momento.

Me pregunto si es esto productividad o simple pérdida de tiempo. En cierta medida, desde todas aquellas conclusiones he llegado hasta el día de hoy mejorando en muchos aspectos de mi día a día.

En esa época no era raro para mí el llegar a la tarde con esa sensación de no saber en qué se me había ido el día y por tanto decidí atajar el asunto de raíz evitando al máximo cualquier tipo de llamada o mails intrascendentes, aunque con ello me colgaran la etiqueta de maniático, soso o aburrido. Mi objetivo era cumplir con mi trabajo, sacar el mayor provecho personal y profesional de mi compañía y volver a casa temprano...

Trabajar bien y con calidad equivale a trabajar productivamente, por eso considero que el mal uso que se hace del móvil es un time killer de primera magnitud. Desde aquella semana en que analicé cómo otros abusaban de mi tiempo en el momento que a ellos les interesaba y no a mí y que la mayoría de las llamadas eran para asuntos que estaban fuera de mi responsabilidad, tomé medidas que he logrado mantener más o menos hasta ahora.

Lo siento por quien se dé por aludido, pero el centrar tu cabeza en una tarea que requiere de mucha concentración, tomar decisiones que te pueden pasar factura en el futuro (acumulando deudas técnicas o bien hacer una infraestimación de esfuerzo en un nuevo proyecto,  por ejemplo) y hacer algo lo mejor que uno pueda con los recursos y habilidades que tenemos, requiere al menos reducir al mínimo este tipo de interrupciones. Una interrupción es normal, varias en una ahora revela descontrol total en la forma de trabajar. Si no tenemos el control de evitar estas continuas interrupciones podemos incluso sufrir una ansiedad y estrés tremendos. El tener un entorno adecuado de trabajo no es sólo una cuestión de higiene, buenos equipos, etc., también es cuestión de contar con la suficiente tranquilidad para poder concentrarte en tus tareas.

No es lo mismo hacer una tarea muy concreta durante dos horas con una mente completamente absorbida en el trabajo que con una mente que se distrae cada quince minutos por un nuevo mensaje entrante, algunas ventanas de chat emergentes o varias llamadas al móvil. Absurdo. De ningún modo puede ser lo mismo: todas esas interrupciones y falta de concentración, si se producen de manera habitual, al final nos están arrastrando a trabajar mal y poco productivamente.

No creo en al multitarea, más que un mito es una forma de mostrar lo ocupados que estamos (produzcamos resultados o no). Si intentamos hacer dos tareas a la vez vamos a tardar más del doble que si lo hiciéramos primero una y a continuación la otra.

Detrás del fracaso de muchos proyectos de software está una malísima gestión del tiempo. Esto empeora aún más las cosas cuando el proyecto se ha estimado económicamente en base a unos tiempos de trabajo, que es lo habitual.

Los efectos de trabajar dispersos mientras desarrollamos código pueden ser desastrosos: la calidad del mismo depende directamente de la capacidad que tengamos de centrar toda nuestra capacidad creativa en él. Si estas interrupciones o forma no productiva de trabajar la pagamos al final con tiempo, lo primero que vamos a sacrificar son esos ratos de veinte o treinta minutos para hacer refactorings o mejorar algún aspecto de la solución.

Las empresas más productivas no son aquellas en las que sus empleados pasan más horas al día en ella, sino:

• Las que más y mejor planifican.
• Las que tienen roles claramente identificados (sobre el papel y en la práctica).
• Las que aprecian el tiempo y su buena organización como herramienta para obtener resultados.
• Las que consiguen que la gente tenga claro qué tiene que hacer en las próximas semanas.

Recuerdo varias ocasiones en las que ante un problema que se había presentado, un compañero mío me decía eso de "no te preocupes que ahora mismo lo arreglo", y a continuación y después de quedar como el héroe del momento, sacaba su teléfono móvil y llamaba a alguien para preguntarle sobre el asunto... En este sentido, quienes abusan del uso del móvil seguramente sean los que menos aportan en una compañía, ya que parece ser que son los que más dependen de los demás para resolver sus propios problemas. Hay quienes llenan su agenda laboral con reuniones eternas como forma de trabajo habitual (sin comentarios) , el resto del tiempo lo pasan colgados al móvil... 

Si trabajas de freelance entonces ya te habrás dado cuenta de que en cierta medida, lo que vendes son horas de trabajo: si consigues hacer más en el mismo tiempo, aumentarás tus honorarios.

Quizá se me pueda tachar de maniático, aunque lo que persigo siempre es fomentar tanto en mí como en el equipo que dirijo que la mayor parte de las tareas se hagan en un ambiente de calma con el menor número de interrupciones. Esto maximiza la productividad.

No hace mucho mi mujer se pasó por la oficina donde trabajo y me dijo algo así como "si esto parece un convento", a lo que le respondí "gracias, eso es lo que intento"...

Quizá a gestores ignorantes de medio pelo les guste ver a la gente muy atareada, con los teléfonos sonando todo el tiempo, las bandejas de correo saturadas de asuntos y, si es posible, que se queden en la oficina hasta las ocho de la tarde. Me temo que este presentismo caduco tiene los días contados.

Los gestores profesionales intentan que el equipo que gestionan terminen su jornada laboral con el trabajo hecho en tiempo, sin estrés y con la máxima calidad. Sí, es posible y hasta deseable. La diferencia sutil, difícil de ver, no es ni más ni menos que una correcta planificación y gestión del tiempo.

Si a la gente no se les hiciera contratos por tiempo sino por resultados, ¿no saldrían muchos antes de la oficina? Ojalá llegue un día en que esto sea así, en que no se valore por encima de todo el tiempo que se pasa en una oficina sino los resultados medibles de lo que hacemos en ella.

Lo del exceso en el uso del móvil es sólo un detalle: el día está cargado de detalles y momentos similares que poco a poco van socavando sutilmente nuestra productividad, es decir, van tirando a la basura el tiempo de que disponemos, lo cual es lo mismo que tirar a la basura parte de nuestra vida, lo que es aún más deprimente (¿que tenemos sino tiempo?).

Si lo miramos bien, el tiempo es el único recurso que tenemos realmente: si lo usamos correctamente, conseguiremos más y mejores resultados.

Hay que evitar los vampiros de tiempo, hay que evitar que en cualquier momento pueda sonar tu teléfono móvil y sacarte de ese instante de concentración en el que estás trabajando a fondo. Si no consigues concentrate en tu jornada laboral, entonces tú y tu compañía tenéis un grave problema.

Siempre, siempre, absolutamente siempre, quienes más éxito tienen en sus proyectos son los que mejor gestionan su tiempo, así de sencillo.

Tanto es así que hay quienes incluso han hecho de la correcta gestión del tiempo una profesión, como la maravillosa web de Berto Pena. En este ebook gratuito que generosamente cuelga el autor, menciona, cómo no, los siete ladrones de tiempo, entre los que se cuentra nuestro maravilloso smartphone.

A lo largo de esta web así como de El Libro Negro del Programador, se insiste mucho acerca de la necesidad de que una solución software sea mantenible. Es más, si no es mantenible fácilmente, el proyecto puede ser todo un fracaso y traerá consigo un cliente muy cabreado y enojado (que seguramente nunca volverá a confiar en ti) o una compañía que tiene un agujero económico que cubrir.

No se hace software para que funcione ahora, sino para que pueda ser evolucionado y matenido fácilmente con el tiempo. Esto para mí es un mantra que repito y un principio irrenunciable.

Mantener un proyecto software en producción es en definitiva conocer cómo se comporta, tener identificadas claramente las actividades de mantenimiento, poder detectar con sencillez dónde ocurren los problemas pero, sobre todo, tener la capacidad de hacer todo eso de manera eficiente y en poco tiempo.

Administrar, por su parte, está relacionado con lo anterior y es igualmente importante: si la administración de cualquier producto software es ineficiente, estaremos poniendo en peligro su viabilidad en producción.

Por muy bien que funcione aparentemente nuestro proyecto, si este no se puede ni mantener ni administrar correcta y eficientemente, habremos realizado en realidad un proyecto más bien pobre. Para que un software sea mantenible y administrable tiene que desarrollarse desde el principio pensando en su sencillez de mantenimiento y administración.

Realizando recientemente algunas actividades de mantenimiento de la web de la compañía en la que dirijo proyectos software, volví a tener presente este carácter intrínseco tan importante del desarrollo. La web está montada en Drupal y se tenían que actualizar algunos módulos desde hacía algún tiempo. A los que me conocen no les extraña en absoluto que dirija la realización de proyectos software al mismo tiempo que me meto de lleno es aspectos de desarrollo de bajo nivel, ¿acaso se puede dirigir algo sin conocerlo suficientemente?

Existe un proyecto que el mundo drupalero conoce muy bien y que permite realizar las actividades de mantenimiento, supervisión y administración de una web basada en Drupal muy fácilmente y, sobre todo, de manera muy eficaz; se trata, claro está, de drush.

Por poner un ejemplo, si tenemos que actualizar el Core de Drupal de un 7.xx a la última versión (en el momento de escribir esto la 7.32) podríamos implementar los pasos oficiales sobre una instancia stage, que, más o menos, son estos:

• Realizar un backup de nuestro sistema (ficheros y base de datos).
• Descargar la última versión de Drupal.
• Copiarla correctamente manteniendo nuestra carpeta "/sites".
• Ejecutar el script "/update.php".
• Por último comprobar que todo ha ido bien...

Esto es algo habitual y, en mi opinión, que existan tantas revisiones de Drupal 7 para mí es bueno, puesto que cada revisión mejora aspectos del Core o realiza actualizaciones de seguridad.

No obstante, lo anterior puede ser tedioso incluso si se tiene que realizar cada dos o tres meses. En cambio con drush todo lo anterior se puede hacer con:

En una simple línea de comandos realizamos todos los pasos anteriores, por lo que de ser una actividad pesada se convierte con drush en la ejecución de una única orden.

Del mismo modo, con:

, obtenemos una visión general de la instancia de Drupal.

Comento esto como un maravilloso ejemplo de facilidad de manteniemiento: con el primer enfoque podemos tardar 10/30 minutos, con el segundo menos de un minuto. ¿No es esto productividad? Me pregunto si no llenamos nuestro día con actividades similares que podríamos optimizar.

Salvo que estemos haciendo proyectos de prueba o de evaluación y no profesionales que en ningún momento se pasarán a producción, personalmente me preocupo mucho de que lo que se haga ofrezca suficientes posbilidades, información y herramientas para un fácil y ágil mantenimiento y administración. En este punto está la clave del éxito de muchos proyectos software.

¿De qué sirve un producto que ha costado desarrollar X € si el mantenimiento del mismo cuesta el triple? ¿Tiene sentido proyectos en los que existen hasta varias personas dedicadas íntegramente al mantenimiento del mismo? ¿No es esto una evidencia de que las cosas no se han hecho del todo bien durante su desarrollo? Recuerdo hace algunos años cuando dedicaba parte de mi jornada laboral a mantener un sistema de telegestión en un cliente y se me iban las horas buceando en la base de datos con consultas muy tediosas para descubrir y resolver ciertos problemas.

Me pregunto cuántas veces en este tipo de situaciones no tiene efecto esa frase tan española y castiza de "preocuparse por la peseta pero no por el duro" (un duro equivalía en la era pre-euro a cinco pesetas), expresión que en versión tecnológica vendría a ser algo así como "intentar que el desarrollo a corto plazo sea muy barato y no ver que su mantenimiento será muy caro".

En cualquier producto software, se desarrolla una vez pero se mantiene continuamente (al menos hasta que nos quedemos sin clientes).

Del mismo modo, cualquier cliente en su sano juicio antes de comprar algo debería preocuparse por lo que le va a costar el mantenerlo y si su administración es eficiente y ágil.

Es más, podríamos convertir esta misma capacidad en un atractivo más de valor para nuestro producto: su sencillez (y poco costoso) mantenimiento.

Durante mis primeros años como desarrollador de software tuve la enorme suerte de participar en un equipo que estaba dedicado íntegramente al desarrollo de un producto. Incluso teníamos quienes se dedicaban exclusivamente a escribir pruebas (lo que era un auténtico lujo). Hace tiempo de eso y aunque usábamos tecnologías ahora obsoletas o de menos uso (Visual C++, ActiveX, COM, DCOM, etc), la dinámica para la creación de un producto software no ha cambiado en absoluto, aunque desde entonces he abrazado el desarrollo ágil como mejor forma de realizar software.

Estos dos últimos años, sin ir más lejos, me he dedicado íntegramente a dirigir un equipo de desarrollo para la creación de un producto software muy específico para compañías del sector eléctrico. Han sido dos años muy duros en los que hemos escrito muchísimo código, hemos sacado unas cuatro versiones comerciales del producto con éxito (con clientes consolidados) y hemos tenido siempre presente la necesidad de refactorizar, de esforzarnos por mejorar y ampliar las pruebas, de escribir una documentación de despliegue correcta y mantener una gestión de la configuración eficiente. Nada es perfecto, pero el resultado, en mi opinión, me indica que hemos hecho las cosas aceptablemente bien.

Programar algo que funcione es relativamente fácil, crear un proyecto muy particular para un cliente requiere de algunas habilidades más, hacer un proyecto similar pero de mayor tamaño con un equipo de varias personas añade un nuevo nivel de dificultad pero, sobre todo, realizar un producto software que sea válido no para uno sino para cientos de clientes distintos, es otro nivel completamente distinto que requiere de una dinámica muy diferente a la del trabajo en un proyecto particular.

Hay muchas diferencias técnicas y de gestión entre uno y otro escenario y no siempre se distinguen claramente.

¿En qué consiste la diferencia?

La dinámica es tan diferente hasta el punto de que en ocasiones se intenta afrontar el desarrollo de un producto con la presión al mismo tiempo de entregar proyectos con ese mismo producto (haciéndolo todo el mismo equipo). Lo he visto, lo he vivido y es un absoluto desastre.

Aunque cada producto y cada proyecto tienen su propia idiosincrasia, en mi opinión es mucho más fácil entregar un proyecto para un cliente que te indica lo mejor posible qué necesita. Otra cosa distinta es saber productivizar algo a partir de las necesidades de un conjunto de clientes: esto es ni más ni menos que el desarrollo de un producto software.

Muy resumidamente, en un proyecto:

• Hay un trato directo con un cliente que puede ser más o menos difícil de llevar (especificaciones que cambian sobre la marcha, exigencia de tiempos de entrega, etc).
• La funcionalidad a implementar está perfectamente acotada (sí, ya sé, al menos debería estarlo).
• La gestión de la configuración, o sea, la definición de flujos de trabajo, la gestión de versiones de desarrollo y la de producción final, etc., es relativamente más sencilla. No digo que sea trivial, sino que es más sencilla que la gestión de configuración para un producto.
• La gestión del grupo de trabajo se orienta a la entrega del proyecto al cliente en fechas determinadas.
• Las reuniones con el cliente absorben mucho tiempo, sobre todo si se le van haciendo entregas tempranas para su evaluación y corrección.
• El equipo de desarrollo o quien lo dirige no necesita conocer con todo detalle el universo en el que trabaja el cliente y su propio negocio.
• No hay necesidad de hacer partes del sistema flexibles y adaptables a gustos y diferentes exigencias de posibles clientes, ya que sólo hay uno.
• En cuanto al mantenimiento, nos podemos permitir que no sea lo más fácil de mantener (ya que va a haber un sólo cliente), aunque lo deseable es que sea extremadamente sencillo de mantener sin acumular deuda técnica que luego nos pase factura en el tiempo dedicado al cliente, tanto si éste paga ese mantenimiento como si no. Un proyecto difícil y costoso en tiempo de mantener en producción, es un fracaso.
• No hay tantas restricciones en la elección de las tecnologías a usar, sobre todo el proyecto no va a evolucionar demasiado con el tiempo.
• Puesto que existe un único cliente, se puede conocer con antelación el entorno en el que se va a desplegar el proyecto (sistema operativo, tipo de base de datos, hardware, etc.), al menos se puede acordar con el cliente.

En cambio, el desarrollo de un producto es otro nivel distinto y mucho más exigente en el desarrollo de software, porque:

• Hay que conocer profundamente el universo de los clientes potenciales hacia los que te diriges. El producto tiene que resolver algo y aportar funcionalidad para el negocio de los clientes, por tanto, tienes que conocer ese negocio muy bien. No es necesario que todo equipo conozca esto, pero quien lo dirige o determina la funcionalidad sí.
• De este conocimiento del negocio de los clientes potenciales hay que extraer la funcionalidad a implementar: especificar es algo muy pero que muy difícil, especificar bien para extraer historias de usuario o requerimientos técnicos lo es todavía más.
• La gestión de la configuración tiene que ser más exhaustiva, sobre todo si con el tiempo terminas teniendo en el mercado distintas versiones del mismo producto.
• Puesto que la vida del producto puede ser muy larga, hay que hacer mucho más énfasis en la testeabilidad del software y todo o casi todo tiene que estar cubierto por pruebas automáticas. De no ser así, el probar el sistema puede suponer tal agujero de tiempo que puede incluso poner en peligro la viabilidad económica del producto.
• Es mucho más difícil elegir las tecnologías a usar más adecuadas, sobre todo si se estima que el producto software tenga una vida de muchos años, que es lo deseable para rentabilizar la inversión en su desarrollo, claro.
• Hay que ponerse en el lugar de los posibles clientes y adivinar o averiguar cuáles pueden ser sus necesidades específicas y particulares para incorporarlas al producto en forma de capacidades de integración, funcionalidad de particularización, etc.
• Hay que definir el entorno ideal de despliegue del producto, lo que puede ser muy delicado porque esto afectará al coste que tenga el mismo. Cuantos más entornos distintos que tengan que ser compatibles con el producto, mucho más esfuerzo por nuestra parte para probar y probar. Un error fundamental es ignorar el tipo de entorno de despliegue hasta el final.
• Si queremos mejorar el producto para ganar cuota de mercado, es imprescindible recibir mucho, muchísimo feedback desde el momento en que tenemos un primer cliente usándolo. Es más, si podemos liberar un MVP (minimum viable product) cuanto antes, mejor, corregiremos así deficiencias lo antes posible y enfocaremos mejor el desarrollo del producto.

Aunque estas diferencias las debe considerar el responsable del desarrollo del proyecto o del producto, también afectan al día a día de los desarrolladores del equipo de trabajo.

Me pregunto por qué nunca he visto en un currículum una mención del tipo "Desarrollador de productos software" o "Desarrollador de proyectos para clientes finales"; para mí la diferencia es enorme. 

Sin duda, el desarrollar un producto software (o dirigir su desarrollo) requiere de mucha más experiencia y de controlar muchos más parámetros que el desarrollo de proyectos específicos, bastante más cómodos de gestionar (aunque el trato con el cliente siempre es difícil de llevar).

Han pasado varios meses desde que se publicó oficialmente El Libro Negro del Programador después de año y medio trabajando en este proyecto. Desde entonces he recibido muchos comentarios, la mayoría afortunadamente positivos (algunos también no tan positivos); en general, todo me hace pensar que los desarrolladores de software nos quejamos casi siempre por las mismas razones independientemente de dónde realicemos nuestra actividad (Chile, Venezuela, Brasil, España, USA, etc.) y que la manera de entender el desarrollo de software desde el mundo corporativo viene a ser muy similar en casi cualquier parte. Cuanto más grande sea la empresa y su nombre se parezca más a "Consultoría de servicios IT", más se pierde el carácter de artesanía (craftmanship) en el trabajo que se realiza, lamentablemente.

En cualquier proyecto siempre se aprende algo, en ocasiones muchísimo, todo depende de la actitud que afrontemos durante el mismo. Incluso si repetimos el mismo tipo de proyecto, siempre podemos encontrar mejores formas de hacer las cosas, por tanto, el que sepamos aprender y mejorar más o menos depende directamente de nuestra actitud.

Sólo mejoramos si tenemos una motivación interna para ello, nadie, ni nuestro jefe, ni nuestros compañeros, ni nuestra empresa, etc. nos va a hacer mejorar profesionalmente si antes no tenemos esa predisposición. 

Creo que el mejor valor que podemos aportar a nuestra organización es el de mantener siempre una actitud de aprendizaje y adaptacíon continuos y esto se debería apreciar y tener en cuenta en los departamentos de recursos humanos.

Mientras le daba forma al libro fui poniendo por escrito muchas gemas de sabiduría que quería compartir; al mismo tiempo, se asentaban en mí ciertas ideas al tiempo que profundizaba en otras. Escribir un libro es ya en sí mismo toda una lección de humildad y cada capítulo te pone a prueba.

Siempre intenté mantener una actitud activa y de escucha cuando publicaba el adelanto de cada capítulo en la web. Nada peor que pensar que uno tiene la última palabra y la razón absoluta, esta actitud un poco egoica (que no egoísta), actúa como un bloqueo que nos impide descubrir nuevas posibilidades pero sobre todo, nos impide darnos cuenta de nuestros propios errores. Los comentarios de ánimo por el trabajo, sobre erratas y también a veces las críticas anónimas mordaces, me hicieron mejorar mucho el contenido y calidad de la mayoría de los capítulos del libro.

Del mismo modo, uno descubre pronto que hablar sobre ciertos temas como aquel que trata el capítulo titulado Cuando el gestor del proyecto es su mayor enemigo, puede causar cierta incomodidad e incluso incompresión por parte de antiguos conocidos, por lo que se aprende muy rápido eso de que no podemos agradar a todo el mundo (gran lección, por si aún no la conocías). Si precisamente el libro propone mejorar ciertos aspectos negativos y recurrentes de nuestra profesión, obviamente ¡tengo que señalarlos para indicar el remedio!, y que conste que soy el primero en haber cometido casi todos los errores típicos que se mencionan en el libro, de modo que soy un ejemplo fantástico y de primer orden...

En ocasiones el hecho de no hacer incomodar a ciertas personas supone un freno para poner en marcha proyectos, mejorar el funcionamiento del departamento en el que trabajamos, etc. Irónicamente también a veces esas personas que suponen un obstáculo ni siquiera nos caen bien... Lección: ignorar que parte de tu trabajo pueda sentar mal o remover malos sentimientos entre ciertos individuos. Afortunadamente, esto es algo muy puntual.

No es lo mismo pensar que sabes algo y que tienes cierta idea sobre algunos temas que intentar ponerlos por escrito para transmitíselo a otros de una manera clara, sencilla y atractiva; son dos ámbitos de pensamiento completamente distintos, de modo que si realmente queremos alcanzar la maestría en algo, nada mejor que dedicar parte de nuestro tiempo a enseñarlo.

Escribir un libro sobre cualquier tema te obliga a poner en cuestión todo aquello en lo que creías, por la sencilla razón de que lo tienes que justificar y argumentar. Del mismo modo tienes que ganarte credibilidad desde la primera línea, indicando referencias, experiencia, no incurriendo en contradicciones y manteniendo siempre una línea coherente con todo. Nada peor que esos libros de desarrollo de software sobre la tecnología X en los que se intuye que el autor ha realizado más bien pocos proyectos con esa misma tecnología.

De aquí la siguiente lección: si quieres escribir con credibilidad sobre algo para ganar cierta atención, tienes que tener autoridad demostrable en la materia y ser lo más experto posible en ello. Cuanto más experto seas, más atención y seguidores obtendrás. No sólo es bueno sino buenísimo que tengamos nuestro propio blog donde de vez en cuando vamos publicando tutoriales, articulillos, etc. sobre los temas que más nos interesan. Es más, debería ser una práctica habitual y casi obligada entre los empleados de las empresas para mantener siempre un espíritu de progreso en aquello en lo que estamos trabajando.

Escribir sobre algo en un proyecto de más de un año require de mucha disciplina (de muchísima tenacidad) y de aguantar periodos en los que el resto de tus actividades te mantienen exhausto y otros en los que sientes un bloqueo absoluto para avanzar el desarrollo de ciertos temas. Si eres incapaz de mantener cierta rutina para una tarea de duración larga, olvídate ya de intentar escribir un libro.

El Libro Negro del Programador es un proyecto que se ha gestado de noche (a partir de la hora en la que mis dos hijas están ya en la cama...), en fines de semana con huecos suficientes como para poder concentrarme en un tema más de dos horas seguidas y, por supuesto, en vacaciones, quitándole tiempo a tu familia y resto de actividades que realizas fuera de tu trabajo full-time. Por esta razón digo que más que trabajo duro se require de disciplina, el saber aguantar mes a mes aún viendo cómo llevas bloqueado en cierto tema algún tiempo. 

Otra cuestión bien distinta es considerar si merece la pena este sobresfuerzo y esto sí que tiene muchas caras y ángulos distintos.

También es una cuestión de metodología: cualquier trabajo que hagamos, sea del tipo que sea, si nos paramos un momento, damos un paso atrás y lo intentamos planificar y ordenar aunque sea mínimamente, entonces obtendremos mejores resultados y lo haremos en menos tiempo; la productividad es eso, ni más ni menos. 

En el caso del libro me planteé una metodolodía de escritura y revisión de cada capítulo más o menos así:

• Planteamiento de las ideas generales del capítulo.
• Desarrollo del primer borrador.
• Revisión a fondo del borrador.
• Publicación parcial en la web como adelanto.
• Digestión y análisis de los comentarios (curiosamente muchos me llegaban por correo a través del formulario de contacto y no directamente como comentarios en la web).
• Desarrollo de un segundo borrador.
• Revisión de nuevo y etiquetado como finalizado.
• Enésima lectura y si algo no seguía quedando a mi gusto, de nuevo a revisar.

Desde el primero punto hasta el último podían pasar varias semanas, de modo que era habitual que fuera superponiendo el trabajar en varios capítulos al mismo tiempo. De este modo, la lección sobre este punto a mí me parece muy importante: si pretendemos trabajar en un proyecto al que no nos dedicamos al 100% y que se va a alargar mucho en el tiempo, necesariamente tenemos que organizarlo de alguna forma, planteando cómo y qué pasos dar en cada momento (esto es, hay que trabajar con algún tipo de planificación y metodología).

Inicialmente hice un esquema básico de los temas en los que quería trabajar, rescatando muchos escritos personales que llevaba varios años realizando; después de hacer una lista de unos cincuenta temas que quería desarrollar, muchos de ellos fueron finalmente cubiertos en varios capítulos, otros fueron descartados y otros, a pesar de haber escrito sobre ellos, fueron capítulos que bien por extensión, bien por no alcanzar la calidad mínima que yo mismo me exigía o bien por coherencia con el resto del libro, no fueron incluidos en el trabajo final. 

Otra lección para mí muy importante: saber desprenderse de aquello en lo que uno ha trabajado, aunque se hayan dedicado muchas horas en ello. Esto me recuerda al enorme esfuerzo que nos cuesta a veces eliminar parte de una solución software que se ha quedado obsoleta, que nunca se ejecuta o bien que queremos sobrescribir por haber encontrado una forma mejor de resolver un problema.

Para cualquier proyecto personal es importante plantearse una fecha máxima de realización. Establecer una fecha no tiene ningún sentido si no nos comprometemos con ella. Este compromiso con uno mismo actúa como resorte que te obligará a sacar fuerzas en los momentos bajos y te hará pisar el acelerador cuando se acerca el mes en el que te habías propuesto terminar el trabajo. Nada peor que decepcionarse a uno mismo, aunque suene raro.

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.