Rafa G. Blanes Blog

Puff..., casi siempre al comenzar el año el que más o el que menos hace una lista de buenos propósitos, de objetivos para los próximos doce meses. En cierta medida, yo lo también lo hago, pero sobre todo me gusta mirar un poco atrás y ser aún más consciente de dónde vengo (por eso de saber mejor hacia dónde voy).

Y desde luego, puedo decir que ni he tenido un trabajo rutinario desde que terminé la carrera ni que me he mantenido en el mismo tipo de rol. ¿Podría haber sido de otro modo? Pues ni idea, seguramente sí, ya que yo mismo he sido responsable de mis acciones y decisiones. ¿Quién si no?

Echo la vista atrás y ojalá los próximos diez años sean igual de intensos y productivos.

Me gusta Haruki Murakami y me le ha acompañado desde que cayó en mis manos casi por casualidad uno de sus libros allá por el noventa y pico.

A modo de resumen...

Terminé la titulación de Ingeniería Superior en Informática por el 2001, después de presentar un proyecto fin de carrera que me llevó casi un año. Se trataba de una aplicación hecha con Visual C++ y librerías MFC/ATL, para la creación de interfaces de usuario de un producto Scada que realizábamos por aquélla época en la compañía para la que trabajaba. Entonces pertenecía a lo que se denominaba el Grupo de Desarrollo de Software (nada original, por otro lado).

Fruto de este proyecto (que creo que sigue en producción en algún centro de operación ferroviario), fue este artículo que ya en su día publiqué en CodeProject y de título Improving ATL-ActiveX Serialization y mucho, muchísimo profiling y escribir código optimizado. Y ahora que lo pienso, ese artículo fue lo primero que me dio por publicar! Y por cierto, veo que tengo que actualizar la información con la que me registré en CodeProject, portal que sigue siendo para mí referencia hoy día.

Lo más interesante de aquéllo fue que en esa aplicación integré VBA (Visual Basic for Applications), toda una novedad en aquel momento, y también un gran reto técnico.

Acostumbrado a C++, todo el nuevo entorno de .NET framework junto con C#, creó una gran expectativa que abrazamos casi todos en el departamento desde el primer momento. De hecho aún conservo un libro que me regalaron en un evento sobre esa nueva tecnología y que creo que sería de lo primero que se publicó entonces.

Siempre he estado muy ligado a tecnologías de Microsoft, y también siempre me han parecido infantiles y no profesionales las comparaciones y dilemas un poco tontos y muy de nuestro sector entre esto o aquello. Toda tecnología tiene sus luces y sus sombras. Punto.

Sin embargo, desde hace unos años trabajo muy de cerca con Azure (la plataforma de cloud computing de Microsoft y de enorme crecimiento) y sigo con detalle todos los movimientos de esa compañía hacia una visión más "open" del software. De hecho, no en vano, .NET Core y la liberación de algunos productos tradicionales de Microsoft para su funcionamiento en Linux (como Sql Server, nada más y nada menos) es una muestra más de esa mayor amplitud de miras. Y no digo Azure por capricho, es que tengo clientes que funcionan desde esa plataforma con un éxito rotundo.

En 2006 ya estaba trabajando en Suecia en un proyecto de muchos millones de euros; mejor dicho, el proyecto tenía un montante de cien millones de euros pero la parte software, aunque, residual, era crítica: sin ese pilar, todo el proyecto se caía y las penalizaciones económicas por parte del cliente podían poner en riesgo la viabilidad misma del proyecto. Había mucha presión, teníamos que trabajar con prisas, cumpliendo hitos literalmente con la lengua fuera, además de toda la presión de los cambios que supone trasladarte con tu familia a un país muy diferente a España.

Pero aprendí, y muchísimo; fue para mí, a pesar de las crisis que viví junto con mis compañeros, una de las etapas más fértiles de ese periodo. Recuerdo alguna noche entera realizando una actualización de uno de los sistemas en los que se basaba el proyecto.

No había metodología, sólo tirar hacia delante del modo que fuese. Curiosamente, todos mis compañeros que entonces participábamos en ese proyecto para una compañía eléctrica sueca (Vattenfall), ya no están en la misma empresa, incluido yo mismo. Todos fuimos saliendo poco a poco encontrando (o buscando) mejores oportunidades laborales y profesionales.

De aquel proyecto me quedó muy claro la extraordinaria importancia de mantener una mínima metodología y orden en los desarrollos (abajo no había orden porque en el nivel ejecutivo ni lo había ni se fomentaba). Y también de la enorme importancia de un diseño pulcro y eficiente de la base de datos, ya que la aplicación era muy data-centric. La base de datos crecía a razón de millones de registros a diario, de modo que continuamente nos encontrábamos con nuevos cuellos de botella (tanto a nivel de software como de hardware). Todo un reto que finalmente pudimos estabilizar (nos llevó más de un año).

Después volví a España y comencé a interesarme por todo lo ágil y clean-code. Fue una época de lecturas frenéticas de toda la literatura relacionada que encontraba interesante (los libros, cómo no, de Martin Fowler, Robert C. Martin, etc.) y poco a poco fui confirmando ciertas intuiciones acerca de los pilares con los que construir buen software. 

Y como consecuencia natural, muy pronto comencé a darme cuenta de que no todo el mundo entendía igual el concepto de buen software, y que apenas se le prestaba atención a asuntos tan importantes como la organización de un equipo de trabajo, las dinámicas de grupo, la ausencia del concepto de jefe o gestor como aquel que facilita el trabajo de los demás, etc., cuyo resultado termina generando un producto bueno o malísimo.

Continuaba escribiendo software de un modo u otro, a veces con buenas condiciones y casi siempre en muy malas condiciones (exceso de reuniones impuestas, tareas no planificadas para hoy, etc.).

Entre 2008 y 2009 hice mi primera tentativa emprendedora. Y fue un total fracaso, pero me permitió meterme de lleno en Drupal. La idea era buena, pero somo se suele decir, la ejecución lo es todo. Por aquélla época comencé a leer mucho sobre emprendimiento e intraemprendimiento. Siempre digo que dejé esa compañía en la que mantenía un contrato fijo y con buen sueldo porque ya llevaba años preparándome mentalmente para probar otro tipo de cosas. Y es que nos centramos demasiado en la acción, pero se nos olvida una verdad trascendental: no es el hacer sino el ser (lo que somos) lo que provoca cambios verdaderos. Bueno, que enrollo en temas de desarrollo personal...

Entre pequeños proyectos de I+D y el mantenimiento del sistema que montamos en Suecia, tenía tiempo de comenzar a interesarme por otras tecnologías fuera del ecosistema de Microsoft. Comencé a hacer mis primeros proyectos web y a leer todo lo que podía sobre Drupal. Y, por supuesto, abracé NodeJS desde el primer momento. Entre otras cosas.

Tanto fue mi entusiasmo por Drupal que terminé participando como ponente en dos sesiones (esta y esta otra) en la Drupalcamp de 2011 en mi ciudad. Descubrí ese ecosistema y una comunidad muy implicada y estimulante.

Comencé a hacerme cargo de la gestión de equipos de trabajo sobre el 2009. Y no tenía ni idea de qué iba aquello, así que leí muchísimo al respecto y lo intenté hacer lo mejor posible.

La empresa para la que trabajaba entonces (la ingeniería Telvent Energía, ahora propiedad de Schneider Electric), no se puede decir que fuese una de esas cárnicas, pero lógicamente, la presión de sacar proyectos era alta. Como en todo, hay momentos buenos y malos, pero todo lo que quiero recordar de aquel periodo (trabajé en esa compañía desde el 2000 hasta el 2012) es bueno y hasta excepcional, y considero que no todo el mundo tiene la suerte de caer en una empresa y tener las experiencias nacionales e internacionales como tuve en Telvent, asistiendo a eventos importantes, etc. Viajé varias veces a USA (estuve en semana asistiendo a TAP program de Microsoft en Seattle, toda una experiencia viendo, oyendo y hablando con auténticos gurús, de los de verdad), así como viajes a diferentes ciudades de Suecia, Holanda, Eslovenia, etc. y hasta una semana en Beirut.

Pero el ciclo se fue acabando y comencé a interesarme por otras cosas y otras posibilidades laborales. Digamos que dejé de verme en un futuro lejano trabajando para la misma compañía.

Artículo disponible en epub y pdf:

Me llama mucho la atención cómo a lo largo de los años puedo haber trabajado en aplicaciones con .NET en C#, con javascript utilizando Angular y NodeJS, y también con PHP cuando estaba más centrado a hacer módulos en Drupal, y cómo con todos esos lenguajes con sus respectivos entornos de desarrollo se pueden aplicar las mismas buenas prácticas.

Hay veces que éstas se refieren a procedimientos de trabajo o al modo de estructurar un proyecto, otras hacen referencia a aplicar patrones de diseño e incluso antipatrones para detectar precisamente lo que no se hace bien. En otras ocasiones, son sencillamente prácticas habituales que hace la mayoría de la gente que usa una tecnología en particular (de ahí, por ejemplo, los proyectos de scaffolding).

Un buen proyecto software debe oler a buenas prácticas, de principio a fin, desde la arquitectura del mismo hasta la evolución de las funcionalidades que se le van añadiendo poco a poco.

Nada peor que una aplicación, proyecto o sistema en el que no se pueda ver claramente cómo están implementadas esas buenas prácticas.

Y es que además tienen algo en común: la mayoría de ellas son fáciles de implementar.

Y como me gusta escribir... pues voy a ir hablando de ellas, de aquellas con las que yo directamente he visto que tienen más impacto en la mejora de la calidad de un proyecto software.

Un aviso a navegantes: en muchas ocasiones los beneficios de estas recomendaciones no se ven claramente, ni siquiera en el corto plazo, y su impacto positivo a medio y largo plazo es más una cuestión sutil que sólo se aprende cuando has cometido todos los errores posibles y entonces se hace la luz y dices algo como, "ahora sí que lo entiendo".

Para mí la implementación de repositorios de datos es una de las prácticas más útiles en cualquier proyecto software.

El principio general de implementar un repositorio de datos vendría a ser el siguiente:

Todos los accesos a los datos que utiliza una aplicación (vengan de bases de datos, entidades de datos del mundo cloud, datos en caché, etc.) deben realizarse desde un único punto.

Dependiendo de la tecnología y del tipo de aplicación que se esté desarrollando, ese único punto se entiende por un módulo con sus clases, una librería, una API, un servicio REST, etc. Lo importante es que todos esos accesos estén centralizados y bien localizados en el proyecto.

¿Qué beneficios se obtiene de esto? Son muchos, muchísimos, algunos de ellos no fáciles de ver en un principio.

Por resumir, centralizando el acceso a los datos conseguimos:

• Cumplimos con el principio SoC, (separation of concerns o separación se intereses), básico en el desarrollo ágil. De este modo tenemos una parte muy concreta y localizada del proyecto especializada en acceder a los datos que utiliza.
• Se evitan duplicar código repitiendo los mismos accesos a los mismos datos a lo largo de la solución. En lugar de ejecutar algo como un "select * from dbo.users where userId = 20" cada vez que se necesita la información de un usuario, tenemos algo mucho más general como "data.getUserById(20)" (esto es un sencillo ejemplo en pseudocódigo, eh!).
• Se simplifica la solución y se reduce el número de líneas de código. Al estar encapsulado el acceso a los datos en métodos muy concretos, no necesitamos ensuciar u ofuscar la lógica de negocio de la aplicación con detalles de acceso a los datos (tales como abrir una conexión a la base de datos, cerrarla, etc.), y ni hablar cuando esos accesos con más complejos y necesitamos transacciones o joins anidados.
• Es más fácil ejecutar un análisis sencillo de profiling: tan sólo repasando en el objeto repositorio a qué datos se accede y cómo, podemos determinar qué índices hacen falta, en el caso de bases de datos relacionales e implementar tests de rendimiento que se puedan ejecutar continuamente.
• Conseguimos desacoplar la solución de cómo ésta accede a los datos. ¿Y si mañana cambiamos de motor de base de datos? ¿Y si por escalabilidad se decide distribuir los datos en diversas bases de datos incluso con diversas tecnologías? Nada peor que empañar todas las partes de la solución con los detalles de acceso a los datos. Puesto que todo está encapsulado en el repositorio, tan sólo hay que tocar éste. El resto de la aplicación, ni se entera del cambio.
• Con la implementación del repositorio, al estar éste desacoplado, se pueden crear tests específicos, unitarios y de rendimiento.
• Es trivial también crear mocks. ¿Qué pasará cuando la tabla "usuarios" tenga cien mil registros? ¿Aguantará el front-end? Con un repositorio de datos es fácil simular diversas situaciones en previsión de problemas de escalabilidad pero sobre todo, que esas situaciones pueden estar respaldadas por pruebas.
• Al estar todos los accesos centralizados, es más fácil para la persona encargada del desarrollo de la base de datos y su acceso trabajar en esa área especializada.
• Al no estar dispersos por la solución todos los accesos al repositorio de datos, las migraciones del mismo no terminan en pesadilla...

Hace un tiempo se hablaba en ciertas tecnologías de la capa DAL (data access layer), que vendría a ser el mismo concepto pero más ligado a bases de datos relacionales.

Si se utiliza algún tipo de ORM que crea objetos alrededor de las entidades de datos, ¿deberían esos objetos viajar a lo largo de la lógica de negocio? Esta pregunta me la encuentro recurrentemente, y mi opinión es que no, puesto que de ese modo la aplicacíon tiene una dependencia clara de la tecnología ORM utilizada. Los objetos que se deberían distribuir a lo largo de la lógica de negocio serán similares pero no ligados a la tecnología ORM usada (son los que se llaman los data transfers objects o DTOs).

A ver, al final hay que aplicar el sentido común (con un poco de experiencia y hasta de suerte...): si trabajamos en un proyecto cuyo ciclo de vida es muy claro y sabemos que se terminará y que no va a evolucionar, pues nos podemos tomar cierto tipo de licencias, pero si tenemos entre manos un producto o proyecto que crecerá y evolucionará en funcionalidad a lo largo de muchos años, entonces sí hay que cuidar mucho este tipo de decisiones y dependencias, así como aplicar con mayor rigor aún todas las buenas prácticas posibles.

Sí, ya sé, es que a veces no hay tiempo, el proyecto viene muy cerrado en horas, etc. De acuerdo, razón de más para aplicar este tipo de buenas prácticas desde el principio, porque sólo así se podrá avanzar en el proyecto con productividad y mayor rapidez.

Todo esto es más fácil de implementar que de describir; sin embargo, un buen proyecto software que necesita de cualquier mecanismo para persistir datos, tiene que acceder a ellos a través de un objeto / módulo / librería que implemente esta buena práctica.

Algunos enlaces de interés:

The Repository Pattern

Repository Pattern Done Right

No me gusta repetir trabajo ni tareas pesadas que se hacen una y otra vez y que de algún modo se pueden automatizar o al menos indicar lo pasos a realizar para que la siguiente vez no pierdas tanto el tiempo en recordar cómo se hacía ésto o aquéllo. Si te encuentras en esta situación a menudo, que sepas que puedes evitarlo.

Si es verdad que debemos poner el foco en aquello que aporta valor, en las tareas verdaderamente creativas y productivas, entonces tenemos que encontrar la forma de no tener que reinventar la rueda continuamente. No estoy hablando de tareas que hay que hacer sí o sí (como un parte de trabajo) y hablo en sentido general, no sólo desde el punto de vista del desarrollo de software, sino de hacer todo lo posible para que estas tareas ocupen el menor tiempo posible y, sobre todo, no tengamos que pensar reiteradamente cómo se hacían.

Voy a poner varios ejemplos:

• El proceso de publicar una nueva noticia en la web, ya sabes, crear el contenido, fijar bien la url, revisar el contenido, comprobar la estructura del mismo, revisar faltas de ortografía o de expresión, pedir la aprobación del mismo si es necesario, etc. Son varios pasos, sí, pero si este trabajo lo haces una vez cada varios meses, terminar olvidándolo y preguntándote ¿cómo había que poner el formato de las url?
• Si mantienes varias webs, como es mi caso, y además todas con Drupal, y dado que no las actualizo continuamente (actualizaciones de módulos, mejoras de diseño, etc.), puedes encontrarte con que cada vez que vas a actualizar una, tienes que volver a investigar cómo se hacía esto o aquello, como por ejemplo, cómo y dónde guardar una copia de seguridad, cómo etiquetar la nueva versión de la web en GIT o similar, cómo comprobar que la nueva actualización no ha roto nada, cómo desplegar para que no te quede ningún cabo suelto, comprobar la seguridad, etc.
• Llevo dos años usando la herramienta Scrivener para la creación de libros. Su proceso de compilación genera un fichero en format eBook, pdf, docx, etc. Sin embargo, después de generar el fichero tienes que comprobar varias cosas según tu flujo de trabajo y el propósito que tengas. Por ejemplo, si generas un eBook para Kindle, tienes (o deberías), revisar que el epub pasa las pruebas de validación con una herramienta como epubcheck, después tienes (o deberías) abrirlo con la herramienta Kindle Previewer y revisar página a página, y no digamos le proceso de publicación en Amazon.

En fin, son trabajos que realizas que requieren de varios pasos para su realización. Salvo que tengas una memoria prodigiosa, cada vez que los vayas a enfrentar algo se te quedará en el tintero.

¿Resultado? No se terminará del todo bien y se tardará más en realizarlo, aparte de lo tedioso que resulta tener que investigar algo porque lo has olvidado... Y si te fijas bien, parte de tu trabajo lo pasas realizando tareas que bien podrían estar bajo el paraguas de un procedimiento.

Llevo años procedimentando este tipo de tareas e intentando establecer una cultura y hábito en procedimentar en los ámbitos laborales en lo que me muevo.

Crear un procedimiento no es más, en esencia, que establecer en una simple guía los pasos para realizar una tarea. No estoy hablando de esas compañías que para hacerlo todo tienen un repositorio de procedimientos o normas más largos que El Señor de los Anillos, sino de sencillas guías que te puedes hacer tú mismo para evitar tener que recordar continuamente las mismas cosas y así hacerlas con mayor rapidez y seguridad.

Y esto se aplica a cualquier ámbito personal o profesional. ¿Qué sería si no la gestión de la configuración un proyecto software sin un procedimiento entendido por todos los desarrolladores?

Si lo tuyo es el marketing, es posible que tengas establecido cómo documentar tus próximas acciones comerciales así como sus resultados (= procedimientos).

Es sorprendente la cantidad de tiempo que se gana cuando tienes guías sencillas y prácticas para realizar tareas más o menos complejas.

Pero por otra parte, ¿cómo si no muchas personas de una organización, por pequeña o grande que sea, podrían trabajar sin seguir ciertas normas o esquemas de trabajo (= procedimientos)?

Lamentablemente en muchas organizaciones, se terminan aprendiendo las cosas no porque las leas en un documento de bienvenida o algo así, sino porque a algún compañero o compañera le endosan la tarea de explicarte cómo se hacen las cosas (por lo cual también es una pérdida de productividad para él).

Estos son algunos de mis procedimientos que más uso:

• Generación y revisión en la generación de epubs y pdf de cara a su publicación.
• Procedimiento de crear contenidos (como este) en las distintas webs así como su difusión.
• Uso de los repositorios de código para los proyectos en los que trabajo.
• Actualización y mantenimiento de mis webs con Drupal.
• Desarrollo de nuevas ideas y propuestas.
• etc.

Si en tu organización no hay procedimientos de trabajo de algún tipo, chungo. Y si en tu día a día, en la forma de organizarte o de afrontar los distintos proyectos en los que trabajas, pero aún.

Estoy convencido de que las personas más exitosas y las organizaciones que funcionan mejor tienen una fuerte cultura de establecer y usar procedimientos de trabajo ágiles, claro, porque su abuso puede suponer al final todo lo contrario de lo que se desea obtener.

No es la primera vez que me encuentro ante un nuevo proyecto en el que el cliente te exige utilizar ciertas tecnologías para sus desarrollos internos. Se trata de una compañía que tiene su propio departamento para satisfacer las necesidades software de la empresa (web corporativa, intranets, canal de pedidos, gestión de tickets e incidencias, etc.); ahora necesitan externalizar algunos trabajos.

No es que usen esas tecnologías porque sí, sino que es la misma política de empresa la que en su día decidió apostar por ellas y no salir de ahí salvo por un motivo bien justificado. De ese modo, todas las aplicaciones internas tienen cierta coherencia.

Esa decisión puede ser muy arriesgada: ¿y si basamos todos los desarrollos en este motor de base de datos que termina cayendo en desuso o cuya licencia sube de precio escandalosamente? ¿Y si usamos este framework para las interfaces de usuario web y con el tiempo surgen otros mucho mejores y productivos?

¿Acaso alguien tiene una bola de cristal y puede predecir las necesidades de la empresa a años vista? Puff...

Trabajar realizando proyectos software que deben tener una vida muy larga es en ocasiones gestionar muchísima incertidumbre en cuanto a la elección de las mejores tecnologías para ese proyecto.

Yo lo digo a menudo, y no me cansaré de repetirlo: es casi más importante usar bien una librería o framework que usar todo lo último porque sí. 

Por poner un sencillo ejemplo, me encanta Angular, es increíblemente productivo y te permite desacoplar muchos elementos de las interfaces de usuario para poder crear tests sobre ellos. Sin embargo, la nueva release Angular 2 es un mundo aparte en relación a la anterior versión y por tanto, si has hecho algo en los últimos años con Angular 1.x, pues ya sabes que o tendrás que continuar con ello mucho tiempo o tienes que plantear una migración, si te interesa, a la nueva versión. Y cómo no, desde el punto de vista empresarial, esa migración cuesta dinero...

Si el éxito de una compañía consiste, en parte, en mitigar y reducir riesgos, entonces definir el conjunto de tecnologías que usa para sus desarrollos internos puede tener sentido. Este enfoque no es único para grandes corporaciones, de ningún modo, cualquier organización de cualquier tamaño puede implementar esta política.

¿Qué ventajas puede aportar tener lo que podríamos llamar un framework corporativo?

Se me ocurren las siguientes:

• No hay curva de aprendizaje para los nuevos desarrollos: el equipo de trabajo ya domina las tecnologías que se usan.
• Al estar basado todo en las mismas librerías, lenguajes, etc., es más posible poder reutilizar componentes ya desarrollados para el resto de proyectos o aplicaciones.
• El mantenimiento de las distintas aplicaciones es (o debería ser) menor, si se ha definido una forma común a la hora de realizar los desarrollos.
• Es más sencillo plantear los flujos de trabajo, ya que éstos en ocasiones dependen de las tecnologías que se usan.

En el caso de este nuevo cliente, utiliza ExtJS, PL/SQL (bases de datos Oracle) y C# para todos o casi todos los desarrollos, además de procedimientos claramente definidos para la especifación, validación y puesta en producción de los nuevos desarrollos.

A la hora de definir un framework corporativo no hay que juzgar los gustos particulares de cada uno, sino evaluar si todo lo que se quiere usar encaja o no con las necesidades presentes y futuras de la compañía.

En el otro lado de la balanza están otras empresas que utilizan tal dispersión de tecnologías para sus desarrollos que finalmente el mantenimiento de todo termina siendo un gran obstáculo. Basta con ponerse en el lugar de alguien nuevo que llega al equipo de trabajo y que tenga que asumir diez tecnologías diferentes en lugar de un grupo reducido y coherente de ellas...

No, no voy a hablar de nada relacionado con los principios de desarrollo S.O.L.I.D., que, en cualquier caso, recomiendo a cualquier programador conocer en profundidad y, sobre todo, ponerlos en práctica.

En los últimos meses he tenido que leer bastante documentación sobre licitaciones y también he estado inmerso en propuestas de nuevos proyectos en colaboración con otras compañías.

En esas licitaciones, algunas para gobiernos autonómicos de mi país, llama la atención la falta de rigor en las especificaciones. Es más, concretamente en alguna se indicaba que "las tareas a realizar se plantearán con exactitud cuando el proyecto sea adjudicado al licitante". En otra, decía que el licitante debía adaptarse a las metodologías de trabajo más comunes, y mencionaba CMMi, Métrica 3, etc. En fin...

Al mismo tiempo, la mayoría de esos proyectos consisten en evolucionar aplicaciones que ya están funcionando en consejerías o departamentos de esas regiones.

¿Cómo poder estimar el esfuerzo para evolucionar algo sin ver su estado actual? ¿Estará la solución hecha unos zorros? ¿Será el típico proyecto espagueti o en cambio todo se habrá hecho con conciencia, mejoras continuas, limpieza de código, etc.?

Miedo me da encontrarme con algo así. 

En esos proyectos se hablaban de tecnologías que ya existían hacer quince años y que siguen muy presentes aunque bajo revisiones más recientes.

En otro, que no tiene nada que ver con los anteriores, se hablaba de trabajar a muy bajo nivel con cierto tipo de dispositivos, empleando el protoloco DLMS.

Y para variedad, estoy trabajando como colaborador externo para una magnífica compañía nacional, líder en su sector, y de nombre Altafonte. Utilizan un sistema basado en PHP, base de datos MemSQL, etc. A sus desarrolladores los considero unos héroes, por haber sabido avanzar en la solución, la base y el core de su negocio, mientras éste crece con multitud de nuevos requerimientos continuamente.

Pensando en todos esos proyectos, ¿qué es lo que pueden tener en común?

En realidad, tecnológicamente hablando, puede parecer que nada, son completamente diferentes, y sin embargo, desde un punto de vista más integral (holístico dirían en otros contextos), el éxito en todos esos proyectos tan dispares, sólo depende de principios que son comunes y antiguos, y que además no son exclusivos de nuestro sector de desarrollo de software.

¿Qué sería de todos esos proyectos sin una correcta organización y planificación?

Para cualquier cosa que haya que hacer, escribir un libro, ahorrar a largo plazo, realizar un proyecto software cuya solución va a durar años, todo medianamente complejo y que se expande en el tiempo, requiere de organizar y planificar.

Y eso es un trabajo en sí mismo. Lo he visto muchas veces, me temo, se organiza al principio, pero ya después las cosas van cayendo en el olvido. 

Cualquier esfuerzo de organización debe ser continuo y hay que dedicarle un tiempo recurrente, es una tarea más que hay que meter entre nuestras actividades.

El proyecto, aún sin la mejor organización, se puede terminar, claro, pero con toda seguridad se habrá tenido que dedicar un esfuerzo mucho mayor y la gente habrá soportado mayores niveles de estrés.

Todos esos proyectos, ¿se podrían enfocar igual sin una mejora continua?

En cualquier proyecto largo, sobre todo si lo actual depende de lo anterior, hay que tener una actitud de mejora continua sobre todo lo que ya se ha realizado. De no ser así, el tema va creciendo y creciendo sobre bases que no están bien, y llegará el momento en que todo se desmorone.

Hay que realizar restrospectivas cada cierto tiempo; las lecciones que nos dan tienen muchísimo valor para seguir avanzando con pasos seguros.

En software, ¿se mejoran todos tipos de assets?

Se tiende a pensar que las técnicas de refactorización sólo afectan al código de producción.

Pues no, de ningún modo; aunque refactorizar es un término que se aplica al código, el resto de assets pueden y deben ser mejorados al mismo ritmo, sin olvidar que la calidad de las pruebas debe ser la misma que la calidad del código de producción.

A medida que un proyecto crece, hay que mejorar su estructura, su diseño, la documentación, etc.

Estoy hablando de proyectos software que deben ser evolucionados en un periodo de tiempo muy largo, años.

Todo, absolutamente todo, influye para el resultado final sea mejor.

¿Y qué hay de los flujos de trabajo?

Me encuentro que las organizaciones se hacen las cosas de un modo determinado, que puede funcionar mejor o peor, sí, pero no existe la conciencia de establecer claramente un flujo de trabajo para cada proceso que necesita emplear la compañía. Basta con poner por escrito de algún cómo se debe hacer esto o aquello y consensuarlo con la gente implicada.

De ese modo, con el tiempo podemos comprobar las deficiencas, trazarlas y mejorar esos mismos flujos de trabajo.

Podemos estar usando tecnologías de hace diez años u otras más recientes, podemos diseñar una nueva solución orientada desde un principio a alguna infraestructura cloud, una nueva aplicación móvil con la úlima API de Android, o entornos como Xamarin o PhoneGap, o bien actualizar una solución de NodeJS basada en la versión 0.12.x al nuevo salto de nivel con la versión 5.x.x., etc.

Sin embargo, cada vez estoy más convencido de que todas esas tecnologías que evolucionan, van y vienen, son la parte de un puzle mayor. Aplicando correctamente estos principios sólidos a la hora de afrontar tu trabajo, podrás usar una tecnología casi obsoleta o el stack más de moda en la actualidad, pero tendrás así muchas más posibilidades de éxito y adaptación a nuevos escenarios.

Este es un tema tan manido en nuestra profesión, tan pesado, pero al mismo tiempo tan importante, que seguimos años y años hablando de lo mismo y sufriendo las mismas consecuencias una y otra vez.

¿Están bien especificados los proyectos? ¿Se parte de un grupo de requisitos suficientemente amplio? Es cierto que en software ágil ya se da por sentando que los requisitos pueden cambiar, porque de hecho cambian, es lo natural, pero lo hacen a partir de entregas, y esto es bueno y es precisamente lo que resuelven de manera magnífica todas las prácticas y principios de lo ágil.

Sin embargo, el peor vicio de nuestra profesión consiste en no saber o no querer esforzarse lo suficiente en establecer correctamente un documento con el catálogo de requisitos o especificaciones que indiquen qué es lo que hay que hacer. Es de sentido común dejar claro lo que el cliente quiere, ¿no?, sin embargo...

Muchas veces, el que tiene que tomar los requisitos, no sabe cómo hacer ese trabajo, me temo, pero en otras ocasiones, es la pura pereza de hablar con el cliente lo suficiente lo que impide que el equipo del proyecto sepa con más exactitud lo que hay que desarrollar.

Existe una ley universal que deberíamos tener siempre presente:

Cuanto más esfuerzo se dedica a especificar, menos tiempo se emplea en el desarrollo del proyecto.

Esto es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, reuniones, visitas, etc. se nos suele olvidar este principio.

Así de sencillo, así de simple. 

No me me deja de sorprender que compañías 100% de desarrollo e implantación de soluciones software, este trabajo previo e indispensable para crear una cotización aproximada y correcta, sencillamente no se tenga en cuenta con la seriedad que debería. Sí, me temo que puedo contar casos que harían palidecer a más de uno.

Hace un tiempo lanzé una encuesta con el siguiente lema: "El tiempo que se establece para los proyectos, ¿es correcto?"

El 81% de las respuestas seleccionaron la opción "No, se suelen hacer estimaciones cortas y muy ajustadas". Genial, como para recomendar a tus hijos esa profesión...

¿Cómo podemos estimar tiempos si no llegamos a especificar correctamente un porcentaje alto de lo que el cliente necesita?

Es cierto que nos podemos guiar un poco por la intuición después de llevar muchos años trabajando en el desarrollo de productos y proyectos, pero ningún negocio puede sobrevivir basado únicamente en este olfato, ni sería serio para ningún cliente determinar el precio de una manera no profesional: "pues a este, le vamos a cobrar X, más o menos", no, de ningún modo es serio, y sin embargo en muchas ocasiones se hace así, o ojo y con prisas, me temo.

La consecuencia natural de esta forma de hacer las cosas la he comentado mucho en este blog y en El Libro Negro del Programador: desarrolladores sin tiempo de hacer bien su trabajo y presionados, clientes enojados porque no se cumplen las fechas o porque se les entrega algo que no es exactamente lo que han pedido, compañías que pierden dinero, etc. También digo que con frecuencia es el mismo cliente el que te impide hacer el trabajo correctamente y te pone impedimentos.

La solución es bien sencilla, pero como todo lo fácil, requiere de disciplina y no dejarte llevar por la comocidad: no se pasa a la fase de ejecución de un proyecto hasta que no esté en su mayor parte especificado en un documento; pero, lo más importante, ese documento debe estar consensuado con el cliente. No es necesario que ese documento sea el que contenga los requisitos software, sino que la especificación puede estar en el mismo lenguaje con el que el cliente habla y entiende su negocio; de ahí, se extraerán después los requisitos software pero es suficiente para hacer una valoración de tiempos más acertada.

Pensándolo bien, en una compañía es vital gestionar los riesgos, ¿no es un riesgo ejecutar un proyecto por debajo del precio que se va a cobrar por él?

Esta falta de seriedad en la especificación la puedo comprobar continuamente y si de otras muchas cosas dudo, de hecho, suelo dudar de casi todo, en esto no hay nadie que me pueda rebatir. La buena ejecución de un proyecto depende enormemente de lo bien especificado que esté. Parece una perogrullada decir esto, pero como sabemos del día a día, a veces es difícil ponerlo en práctica. Otra cosa es que aplicando correctamente buenos principios de desarrollo, el proyecto sea mantenible y evolucionable cuando se planteen nuevos requisitos.

Otras veces es el mismo responsable comercial de la compañía el que quiere cerrar el tema (lanzándole la pelota o el marrón a otros), y a otro asunto.

Así son las cosas. Sin embargo, un buen responsable de equipo o de proyecto, no debe aceptar la puesta en marcha de un nuevo proyecto si no tiene claro en su mayor parte lo que hay que hacer. Es como si le pidiéramos a un constructor que nos levante una casa: ¿y cómo la hago?, pues mira, más o menos...

"...no vaya a ser que cambie tu modo de pensar". Leí una vez en un libro de esos de desarrollo personal.

Comienza el año y después de tanto Rosco de Reyes (dulce típico en España y que pone fin a las navidades), te das cuenta de que ya es enero, vuelves al trabajo y esa enorme lista de propósitos y proyectos que alegremente hacías en diciembre, ahora la tienes delante y es hora de empezar a hacer cosas.

O sea, lo de siempre, comienza el camino para que al final del año, si nos seguimos acordando de esa lista, nos demos cuenta de que no hemos conseguido ni la mitad de la mitad. Es más, yo creo que esas promesas de mejora para el nuevo año entrante son más bien un tirar hacia delante y una excusa para justificar lo difícil que nos resulta actuar y hacer lo que debemos y queremos hacer. ¿O no?

Vale, sí, yo soy el primero que uso esas listas, las uso desde hace mucho con mayor o menor éxito. Uno de mis propósitos para este año se seguir leyendo más y mejores libros de todos los temas que me interesan, muchos de ellos de tecnología, otros de desarrollo personal, etc. 

¿Es que puede ser de otro modo? ¿Puede existir cualquier negocio o profesión que no avance sin seguir aprendiendo? Todo evoluciona, si no lo hacemos al mismo ritmo que todo lo demás, podemos terminar intentando vender algo a clientes de un mercado que desapareció o se transformó hace mucho.

Discrepo cuando oigo hablar de que estamos en la sociedad del conocimiento; puede que sí, que la economía sea cada vez más del conocimiento, pero las personas, en general, estamos lejos de darnos cuenta del impacto que esto supone en nuestra forma de aprender y evolucionar profesionalmente. Si los negocios cambian, lógicamente sus profesionales también. 

Es verdad que ahora disponemos de enormes recursos de aprendizaje a un coste ridículo en forma de blogs, webinars, podcasts, seminarios, videocursos, maravillosos libros en Kindle o de Google Play desde 0.99€ y que leemos desde el móvil; puede que ahora tendamos a leer más que antes y que leamos y nos informamos de otro modo. Pero paradójicamente, acumulamos tal cantidad de información que comienza a ser un problema esa misma sobreinformación porque somos incapaces de extraer conocimiento de todo ello. La hiperinformación (y la adicción a ella) comienza a considerarse algo patológico.

Lo importante no es llenar la cabeza de datos, sino saber qué hacer con ellos, a no ser que tengas complejo de loro y te guste repetir la información que lees, claro.

O sea, que no es lo mismo, en mi opinión, leerte todos los feeds de tu agregador cada día o cada dos horas, que empaparte un sesudo libro de Jeremy Rifkin analizando un tema en concreto en profundidad. Sin embargo, para la mayoría de la gente estar más informado es hacer justamente lo primero, y sólo lo primero.

No puedes avanzar en ningún tema si no lees en profundidad sobre él, y para ello hace falta la organización estructurada de un buen libro que analice el contexto, el planteamiento, las diversas experiencias sobre ese campo y que incluso se atreva a realizar algún tipo de prospección al respecto. El libro no ha muerto, de ningún modo, puede estar en la unidad de cuidados intensivos el formato papel, pero lo que es estructurar el conocimiento en forma de libro, eso va a pervivir, espero, muchísimos años. El saltar de titular en titular es para mí frivolizar y no llegar a nada.

En software ocurre exactamente lo mismo. No es igual aprender una nueva tecnología leyendo tutoriales por aquí y por allá que sólo tocan la punta del iceberg; puede servir para jugar un poco, para resolver problemas puntuales cuando ya conoces bien esa tecnología, yo lo hago muchísimo y lo voy a seguir haciendo, claro; también hay posts y tutoriales extraordinariamente buenos.

No obstante, si quieres realmente profundizar en esa tecnología, coge un buen libro y empápatelo de arriba abajo; es más, recomiendo no usar sólo un libro de referencia para ello, sino varios, ya que rara vez un único libro cubre todo lo relevante (por mucho que en el título ponga "La biblia de...").

Yo, al menos, eso es lo que hago cada vez que siento la necesidad de llegar al fondo de algo: quizá husmeo un poco por aquí y por allá en blogs de gente que sepa más que yo sobre ese tema en particular, pero siempre buscando una buena referencia bibliográfica con la que comenzar. Después asedio mi cabeza durante el tiempo que sea necesario con información sobre ese tema, libros incluídos, hasta que me siento suficientemente maduro como para seguir adelante. No es saber por saber, es aprender para hacer algo con todo ello.

Con un primer libro vas a conocer globalmente esa tecnología y seguro que encontrarás multitud de referencias para avanzar por caminos paralelos llegado el caso.

No se puede aprender seriamente algo únicamente picoteando en tutoriales de quinientas palabras; lo siento, pero no funciona así, el libro sigue siendo necesario porque te da esa visión global tan necesaria para saber usar bien lo que sea que necesitas aprender. Para mí, en un libro el autor te viene más o menos a decir "hey!, he trabajado mucho este tema y todo esto que te cuento aquí es mi experiencia sobre ello".

Así que esta es la paradoja: creemos que vivimos en una sociedad de la información cuando en realidad lo que queremos decir es que ahora estamos sobreinformados de muchas cosas pero seguimos con la misma falta de conocimiento que hace veinte años, y eso ocurre en todo, en tecnología, gestión de negocios, marketing, etc. Tenemos a nuestra disposición el conocimiento de forma inmediata y a coste muy pequeño, sin embargo el ciudadano medio, por lo general, no lo usa y se queda sólo en los titulares. Es una pena.

Por favor, ¡escribidme para decirme que estoy equivocado!

Acabo de comenzar el año con dos autoregalos, dos libros que prometen muchísimo.

Uno de ellos es el libro de Lazlo Bock sobre cómo están cambiando en algunas compañías la forma de organización del trabajo. El otro se llama El Mundo que Viene, de Juan Martínez-Barea, en donde se habla sobre cómo la meritocracia será un valor fundamental en el futuro (vaya, por fin).

No podemos progresar en un mundo que cambia continuamente sabiendo lo mismo que sabemos hasta ahora.

Lo siento, hay leer, pero incluso leyendo mucho te puedes encontrar abrumado y sin llegar a un conocimiento apropiado de nada e insuficiente para actuar y conseguir nuevos resultados, de ahí que leer libros bien estructurados y con la suficiente profundidad sea imprescindible, nada que ver con la inmediatez de los titulares de blogs de tecnología a la que somos tan aficionados (yo el primero, eh!), que son necesarios, claro, pero no suficientes para profundizar en nada.

El libro no está muerto, de ningún modo, el que sí lo está es quien piensa que va a obtener mejores resultados sin aprender nada nuevo.

Joer, qué serio me ha quedado esto.

Green Kiwi Games © es un proyecto en el que he ido trabajando muy poco a poco en los últimos meses y que constituye lo que se llama un producto mínimo viable (MVP), esto es, un producto o proyecto que muestra la esencia de algo y que se expone para validar su propuesta de valor (o sea, si a la gente le resulta útil o no).

Si una cosa he aprendido en los últimos diez años, y no exagero, es que tu día a día como profesional termina reduciendo tus habilidades a un conjunto de tecnologías, las que usas lógicamente en la compañía para la que trabajas. Y esto no es bueno más aún cuando el cambio en nuestra profesión es vertiginoso. No obstante, en tecnología en general y en software en particular, las posibilidades son tremendas y la cantidad de tecnologías consolidadas y stacks maduros que existen te obligan a tener que estar al día si en unos años no quieres estar más obsoleto que el T-800 de Terminator.

Pues bien, Green Kiwi Games ha sido para mí la forma de profundizar en el stack MySql+Express+AngularJS+Nodejs (lo que se suele llamar MEAN, pero en esta ocasión sin MongoDB...).

Ya he hablado en alguna ocasión brevemente sobre cómo enfocar proyectos de emprendimiento desde el punto de vista del software, campo en el que he tenido mis éxitos pero también mis fracasos. Es un tema muy amplio y lamentablemente muchos proyectos fallan no por falta de una idea que pueda funcionar, sino por la ejecución del mismo proyecto y falta de disciplina para llevarlo a cabo en el tiempo. Buena ejecución, tenacidad y disciplina en el trabajo, esta es la receta en mi opinión.

En cualquier caso, todo parte de una idea que termina siendo lo que nos anima a seguir adelante porque de algún modo creemos en ella. Ahora bien, ¿cómo saber si los demás también la ven útil? Desde luego no es contándola, sino creando algo que lo muestre, algo que se pueda tocar y evaluar. De ahí lo del producto mínimo.

Pero, ¿cómo surgió la idea y qué es Green Kiwi Games? Pues bien, hace un tiempo me encontré con ciertas personas que hacían por su cuenta juegos de cartas, pero con un esfuerzo tremendo al no dominar ninguna herramienta informática y de forma totalmente manual. ¿Por qué no habilitar una web en donde el usuario subiera las imágenes y que la aplicación web se encargara de generar un pdf con las cartas listo para impresión? Sencillo, nada de otro mundo. Una idea, para ser buena, se tiene que poder explicar con muy pocas palabras. La innovación no trata de generar productos cercanos a la ciencia ficción, en cosas sencillas y banales se puede innovar también; es más, la mayor parte de la innovación pertenece a este último grupo. Tendemos a mitificar la innovación.

Eso es Green Kiwi Games, un sencillo portal que le permite a un usuario crear juegos de cartas de manera muy fácil, casi a golpe de clic. En un mundo en el que va dominando el do-it-yourself, descubrí auténticas comunidades dedicadas a hacer juegos de cartas personales y de distribución fuera de los canales habituales comerciales.

Si embargo, no hay dos sin tres, de modo que aproveché este mini proyecto para meterme de lleno en tecnologías que me apasionan, de modo que puedo decir que he pasado por todos los elementos que debe dominar un full-stack-developer y que describo a continuación.

Muy brevemente resumo todas las piezas que he ido utilizando, al menos las más relevantes:

• Por supuesto NodeJS. He sufrido en el camino el cambio producido con la integración por fin de io.js y la creación de la Node.js Foundation, magnífica noticia para quienes amamos este entorno.
• Express para la construcción de la infraestructura de la web con infinidad de módulos relacionados y bien integrados.
• AngularJS para el front-end.
• Muchísimas pruebas unitarias con Mocha para su ejecución y Chai como librería de aserciones.
• Lodash que me ha salvado la vida para construir código más legible. Impresionante el trabajo de la gente de esta librería.
• FabricJS tanto en el front-end como en el back-end para la construcción de las cartas.
• ImageMagick para el tratamiento de imágenes.
• Redis para el mantenimiento de las sesiones de usuario así como para almacenar ahí información útil y relevante y no abusar de la base de datos.
• S3 de Amazon para el almacenamiento masivo de las imágenes y pdfs finales.
• wkhtmltopdf para la construcción de los pdfs con las cartas construidas.
• Grunt como gestor de tareas para la construcción del proyecto de cara a su despliegue.
• Despliegue en DigitalOcean con nginx con un certificado adquirido desde Namecheap.
• Y muchíisimos más paquetes y librerías.

Del mismo modo, este proyecto me ha permitido adentrarme en todo lo relacionado sobre rendimiento y seguridad web, tema fascinante y que dejan muy de lado muchos desarrolladores de aplicaciones web y con un enorme campo comercial por delante: optimización de todos los assets del proyecto, carga retrasada de imágenes sólo si se muestran en el navegador, minificación de ficheros, optimizaciones en javascript, reducción del número de requests, seguridad frente a los ataques más comunes, etc. Este tema me gusta muchísimo y de hecho estoy escribiendo unos cuadernos prácticos de cara a su publicación en 2016.

¿Y ahora qué? Realmente es después de crear el producto mínimo viable cuando se abren todas las posibilidades: el MVP es un primer paso con el que validas cualquier idea, después hay que recibir todo el feedback posible para mejorarla, pivotar sobre algunos conceptos o bien tirar la idea a la basura y a otra cosa. Esto es así, aunque lo bueno es que podemos probar ideas con una metodología sin reinventar la rueda continuamente y sin dedicar demasiado esfuerzo en ello.

Mi interés fundamental con Green Kiwi Games es ayudar a esa comunidad de creadores de juegos de cartas a realizardos y fomentar esa actividad. También conocer desde dentro la construcción de un proyecto real con esas tecnologías y no quedarme en sencillos artículos que te muestran sólo la punta del iceberg. Sobre todo, conocer de primera mano cómo se debe construir un proyecto de esta naturaleza para su escalabilidad futura en caso de tener miles de usuarios.

Si quieres conocer una tecnología, la mejor forma es construir un proyecto real con ella.

Para la idea esencial me he centrado en lo que considerado importante, no obstante, los próximos pasos serán:

• Hacer la web responsiva. Ya sé que existe el enfoque mobile-first pero para avanzar hacia el MVP lo descarté en un principio.
• Añadir características muy poco a poco según el feedback recibido. Me gusta en enfoque de Accuradio: si usas a menudo su servicio para escuchar las maravillosas compilaciones de música que hacen, te darás cuenta de que poco a poco van agregando pequeños detalles y mejoras, muy sutilmente.
• Si el proyecto despega, lógicamente habrá que prepararlo para su explotación comercial con un modelo de negocio que lo haga sostenible, para lo que contaré sin duda con la empresa para la que trabajo. Para esto hay gurús que opinan que el proyecto debería generar ingresos desde un primer momento, aunque este es un proyecto personal con el que sencillamente me relajo trabajando en cosas que me gustan. Si el proyecto o su futura evolución funciona, los ingresos llegarán de un modo u otro.

Si una cosa importante he aprendido con Green Kiwi Games, es el poder de las pequeñas tareas mantenidas en el tiempo: pequeños ratos, unas horas los fines de semana, lecturas en el baño de artículos relacionados (...), en fin, cualquier momento es bueno, al cabo del tiempo, has acumulado cientos de minitareas que terminan generando un proyecto con cierta madurez y listo para su publicación. La satisfacción de hacer un despliegue final a disposición de todo el mundo es casi adictiva.

Yo insisto siempre en lo siguiente: si trabajas para una empresa, la mejora forma de mejorar tu trabajo y convertirte en intraemprendedor es crear proyectos personales en areas que no tocas frecuentemente. Las habilidades que aprendes en estos últimos terminan volcándose en tu día a día en la compañía para la que trabajas, así que todos ganan.

Uno o dos proyectos personales al año al margen de los que ocupan tu dedicación profesional si es que trabajas para una compañía: ese es siempre mi objetivo y paradójicamente, eso me ha permitido mejorar mi trabajo en la empresa sustancialmente.

Hace unos meses leíamos sorprendidos la noticia de que un grupo de estudiantes francés había descubierto miles de bases de datos MongoDB con acceso público y abiertas, no por alguna vulnerabilidad en ese engine de base de datos, sino por malas prácticas de quienes las habían implantado. Terrorífico si se piensa por un momento; puede parecer anecdótico pero el fondo de la cuestión es que la información de esas bases de datos podrían poner en situación de vulnerabilidad a personas, instituciones e incluso países. Sin llegar a exagerar, ese caso probablemente no sea más que un gota en el océano.

Admitámoslo: cuando se trabaja desarrollando proyectos, casi siempre terminan entregándose con presión de tiempo y dejando una larga estela de TO-DOs y de elementos que se podrían mejorar. Es más, pocos clientes, sobre todo si son de ese tipo que no entienden demasiado de tecnología porque su negocio o actividad es otro, ignoran cómo evaluar la calidad de lo que se les entrega: mientras funcione y lo que ven les guste, no habrá problemas, todos contentos, nosotros hemos entregado un proyecto, la compañía lo habrá cobrado y a otra cosa.

Cuando hablamos de software, hablamos de un medio que permite que otras actividades funcionen: la gestión documental de una compañía, el blog de un freelance, al firmware de una lavadora o un sistema Scada que gestiona una central térmica.

Sin embargo, ¿existe realmente interés por encarar la seguridad en el contexto de cualquier proyecto software sea del tipo que sea? No estoy hablando de software para aeronaves, plantas nucleares, etc., sino aplicaciones de cualquier tipo realizado por cualquier empresa para clientes no excepcionales (que, por otra parte, intentan pagar lo menos posible).

Esto es lo que quiero decir: la seguridad informática apenas es un aspecto relevante para la mayoría de desarolladores de software, y es así no porque ignoremos técnicamente cómo afrontar esos temas, sino porque en general no existe una cultura tecnológica extraordinariamente preocupada por exigir consumir software con todos los estándares de seguridad. La ciberseguridad sigue siendo más un término de películas de ficción que una auténtica preocupación masiva en toda nuestra industria.

Tanto si se trata de un simple proyecto que de ser vulnerado puede tener poca o ninguna repercusión, hay muchos otros proyectos para los que cualquier incidencia de seguridad puede ser un auténtico problema: desde la pérdida de horas de trabajo y una enorme frustración para la gente afectada hasta la seguridad física de personas e instalaciones. Y no exagero, en absoluto: por poner un ejemplo, uno de los productos que comercializamos en la compañía para la que trabajo puede dejar literalmente sin luz a miles de abonados de compañías eléctricas. ¿Y si alguno depende de un soporte vital? Es un tema bastante serio que conviene no frivolizar.

La seguridad es importante, extraordinariamente importante, sobre todo en un momento en que toda nuestra economía no sólo es adicta al petróleo sino que también depende de la tecnología para seguir funcionando. Para muchas plataformas, una hora sin funcionar puede significar mucho dinero (aparte de dar una imagen poco profesional), pero también para una pequeña web de una empresa familiar puede suponer muchas horas perdidas para resolver el problema.

Digo yo que para tratar mejor el tema de la seguridad en nuestros trabajos debemos tener también cierta faceta de hackers y actuar como pentesters.

No hace falta pensar en la seguridad como se plantea en series como MrRobot, no es un tema que vaya de super-hackers con problemas de socialización y de una subcultura de frikies. La seguridad en software está también en nuestro día a día, sea cual sea el tipo de software al que nos dediquemos, no importa las plataformas que usemos: debe formar parte del roadmap de cualquier desarrollo en el que trabajamos.

Pero, ¿cómo? Es cierto que los mismos responsables de proyectos pueden frivolizar sobre este tipo de cuestiones, lo pueden ver más como un coste que como un elemento de calidad diferenciador. Del mismo modo, en cualquier actividad profesional hay que minimizar los riesgos, por tanto, como tareas de desarrollo hay que incluir algún tipo de aseguramiento de la seguridad, tanto a nivel de diseño, configuración de la plataforma en la que nos basemos y también a nivel de despliegue, y, lógicamente, el cliente debe ver ese trabajo como una aportación positiva al proyecto (y por tanto estar de acuerdo y pagar por él).

¿Será un buen momento para diferenciarse profesionalmente como desarrollador experto en seguridad? Desde luego el tema da para mucho.

Lejos de declaraciones grandilocuentes, algunos sencillos ejemplos que podemos tener en cuenta con relativamente poco esfuerzo:

• Se si usa cualquier repositorio de datos con información sensible, ésta se debe guardar encriptada.
• Las contraseñas para acceder a middlewares o servicios externos deben ser fuertes, como las security keys que se usan en Amazon o Azure para acceder a servicios en la nube.
• Si se usa un fichero con contraseñas de acceso de algún tipo, tenemos que garantizar que este no esté accesible una vez desplegado el proyecto (cosa obvia) y, por qué no, pensar también en encriptar el mismo fichero.
• Si se tiene un cliente web, las validaciones de datos se deben hacer tanto en cliente como en servidor.
• Cualquier infraestructura software IT que se utilice (servidores web, protocolos, sistemas operativos, bases de datos), se debe revisar en producción y garantizar que estén correctamente configuradas.
• Y un larguísimo etc...

Por otra parte, habrá clientes a los que les gustará muchísimo ver un anexo sobre seguridad en la propuesta del proyecto. En mi opinión, una empresa que provee software y hace hincapié especialmente en la seguridad de sus desarrollos, además de necesario, se debe percibir como de mayor calidad, por lo que puede ser un argumento diferenciador con respecto a los competidores.

La seguridad en software tiene muchas vertientes; es un tema tremendamente extenso. Como simple perla, para cualquier aplicación web:

• ¿Aguantaría un ataque DDoS (ataque por denegación de servicio)?
• ¿Incorpora filtros XSS (cross-site scripting) y evita Sql Injection?
• ¿Tiene en cuenta el servidor web, sea el que sea, la vulnerabilidad http pollution?
• ¿Está el servidor web configurado correctamente para ocultar la cabecera "X-Powered-By" o tiene implantado el mecanismo HPKP (http public key pinning)?
• ¿Implementa la táctica frameguard?
• ¿Los formularios incorporan el token CSRF (cross site request forgery)?
• Y aquí también otro larguísimo etc...

¿Ejjj, cómo? Yo no me considero experto en seguridad, ni mucho menos, pero es un tema que cada vez me interesa muchísimo más; si desarrollas aplicaciones web y los conceptos anteriores (cogidos al azar de entre muchos otros) te suenan literalmente a chino, ve pidiendo formación a los Reyes Magos del 2016 o un buen lote de libros para mejorar en ese aspecto.

Es cierto que ser absolutamente exhaustivos con todas las cosas a securizar será una labor extraordinaria, pero, al menos, se podría incluir un checklist en cada proyecto que asegure que se cumplen los elementos de seguridad imprescindibles.

Por cierto, y hablando de seguridad ¿por qué los hackers, al menos ciertos hackers mediáticos, aparecen siempre con un aire desaliñado, gorritas, camisetas y con barba de varios días? Curioso... :-)

Esta es la realidad: la mayoría de los desarrolladores y gestores trabajamos en proyectos para un cliente específico final. Es decir, hay un cliente que genera unas especificaciones y un equipo que las desarrolla (en el mejor caso esos requisitos están claros al principio aunque lo habitual es que no lo estén).

¿Pero es que puede haber otra cosa? Claro que sí, no tiene absolutamente nada que ver la dinámica de trabajo en un proyecto que la dinámica de desarrollo de un producto software.

Ya he hablado en alguna ocasión sobre esta cuestión, pero ahora quiero enfatizar qué aspectos en el desarrollo de proyectos se deben cuidar mucho para evitar que tanto los equipos de trabajo como la misma compañía caigan abrumados bajo el peso de multitud de proyectos mal gestionados y mal cotizados.

El desarrollo de un proyecto está lleno de detalles y todos cuentan: el resultado final es un conjunto de aspectos que se han ido haciendo suficientemente bien, como en cualquier otra actividad profesional. Si descuidamos algunos, se notará en el resultado final. Sencillo de entender, ¿no?

Recientemente he visitado una empresa en la que he visto que se dan algunas de estas circunstancias: gente con ganas de hacer las cosas mejor pero agotadas de las guerras del día a día en que no hay tiempo de pararse un momento y ver qué no funciona o qué se puede mejorar. No hay que ser muy listo para evidenciar qué se está haciendo mal o qué impide que las cosas avancen mejor, el problema es que tú puedes pensar algo pero tiene que ser el gestor del equipo, sus jefes o el responsable de la compañía el que ponga los medios para que la gente trabaje correctamente y decida también cambiar cómo se hacen las cosas. Esto también es algo típico: la incapacidad de ver que los resultados dependen de eso...

Y no sólo se trata de disponer de la infraestructura mínima necesaria, también de mantener una disciplina metodológica en la forma en que se decidan hacer las cosas. Yo creo que no hay más, lo difícil realmente es seguir esa disciplina y los procedimientos establecidos.

He creado esta pequeña encuesta sobre los puntos que vamos a ver a continuación.

Si te sientes identificado con algo de lo siguiente, enhorabuena, perteneces a una cultura de trabajo muy extendida en nuestro sector (con poca productividad y resultados pobres que se pueden mejorar). Todo lo que indico a continuación es demasiado obvio y a muchos les sonará a principios básicos, no obstante, ¿se cumplen en la mayoría de compañias de software?

#1 Un proyecto bien estimado en tiempo nos permite trabajar mejor

Cosa obvia aunque lo habitual es que los proyectos se consigan reduciendo los tiempos al máximo y cotizando las horas por lo bajo..., ¿resultado?, proyectos que tienen que salir sí o sí con poco tiempo y, por tanto, en su desarrollo deberemos ir abandonando las buenas prácticas de trabajo (las conozcamos o no, que esa es otra).

Básicamente, los proyectos se cotizan por horas y éstas por los perfiles de la gente que va a participar en ellos (dentro de la misma compañía suele haber perfiles más caros que otros).

Por tanto, si ese trabajo de estimación de horas no se hace bien, habrá dos posibles consecuencias: o vamos a reventar al equipo con mucha presión (cosa no mala sino malísima) o bien la compañía va a perder dinero (que tampoco es nada bueno, vaya).

¿La solución? La estimación se debe hacer por lo alto y contando con la opinión de las personas más relevantes que van a participar en el proyecto, añadiendo también alguna desviación. Esto es fácil de decir y difícil de llevar a la práctica, de ahí que las habilidades comerciales permitan conseguir esto. Seguramente de este modo va a salir un precio mayor que el cliente va a intentar regatear, que ese es otro tema, no menos importante.

Comercialmente no se puede disparar a todo lo que se mueve sin darnos cuenta de que igual que hay compañías que trabajan mal, también hay clientes que conviene no tener. Difícil decisión en épocas de crisis, claro.

#2 La especificación tiene que ser lo más completa posible

Este es el gran caballo de batalla de nuestra profesión en la que lo normal es que los clientes no tengan claro al 100% lo que realmente quieren o necesitan. No obstante, un buen comercial debe ser capaz de ayudar al cliente y extraer de él lo que quiere.

Lo importante de esto es que se debe adquirir el compromiso de que una vez establecida la especificación, ésta no debe cambiar (al menos demasiado) a lo largo de la ejecución del proyecto, y, si cambia, si nos obligan a cambiarla, entonces tenemos que repercutir en el cliente los excesos de tiempo que supongan. Claro, esto tampoco será sencillo, pero el cliente debe entender que no trabajamos por amor al arte y si los números no salen, pues no salen.

Para ello es necesario un trabajo comercial que sea capaz de llevar al cliente al terreno que nos interesa.

#3 Evitar la dispersión de tecnologías

A menos que la compañía cuente con muchísimas personas con perfiles muy distintos, lo normal es que sólo se dominen algunas tecnologías y se sepa algo de otras.

Al cotizar un proyecto hay que tener en cuenta el grado de conocimiento que tiene el equipo en las tecnologías que se van a usar. Si el equipo no conoce bien, por poner un ejemplo, JSF, entonces estamos obviando la curva de aprendizaje (igual a tiempo) en que se va a incurrir durante la ejecución del proyecto. Es, digamos, un coste oculto que hay que tener en cuenta.

No nos engañemos: si bien hay gente que en sus horas no laborales pasan gran parte del tiempo empapándose de manuales o haciendo proyectos por su cuenta, mucha gente no toca esos temas fuera de la oficina.

¿La solución? Intentar contratar proyectos en cuya ejecución se utilicen las tecnologías que mejor se conocen: esto es garantía de productividad (y rentabilidad).

En mi opinión nada peor que un equipo que le da a muchos palos (para mis lectores latinos, "darle a muchos palos" = hacer cosas muy distintas). Sólo podemos ser expertos en pocas cosas y, por tanto, la rentabilidad y productividad va a venir de la mano de esas tecnologías que conocemos mejor. Estamos hablando de hacer un proyecto rentable, no de querer jugar con MongoDB porque mola y voy a forzar a usarlo en el proyecto X sencillamente porque me gusta, no porque realmente encaje en él.

#4 Hay que usar algún tipo de gestión de la configuración

El día a día en el trabajo está lleno de pequeños momentos y detalles que podemos hacer bien, ejecutar en segundos o hacerlos rematadamente mal. Todo detalle cuenta, de modo que la falta de fluidez en el trabajo se debe a ejecutar mal parte o todos esos detalles del día a día.

No hay nada que afecte más a la productividad de un desarrollador que una mala gestión de la configuración: aunque sea simple, se debe establecer. 

¿Cuánto tiempo hemos perdido a veces porque se ha roto la compilación o porque hemos querido volver atrás en el código y esto ha sido imposible?

No es sólo usar un repositorio de código (me da vergüenza hasta escribir esto, pero es que hay quien trabaja sin usar ninguno), también establecer unos mínimos procedimientos sobre cómo usarlo para un equipo de varias personas.

En cuanto a la gestión de la configuración está todo inventado, no hay que innovar, sólo céntrate en las buenas prácticas buceando mínimamente en Internet.

#5 Hay que crear cierta documentación

Vale, sí, esto es obvio pero ¿hay alguien en la organización que exija que se cierre el proyecto con una mínima documentación? No estoy hablando sólo de la guía de usuario para el cliente final (si es que este la exige), sino de todo aquello que debamos documentar mínimamente para poder retomar el proyecto de manera rápida en el futuro. 

Yo siempre insisto en hacer una guía de diseño con todos aquellos aspectos sobre el diseño y la arquitectura que se deban explicar y que no sean evidentes; también una guía de despliegue exhaustiva que nos garantice que podemos instalar y hacer funcionar el proyecto en un nuevo entorno. Esto es tremendamente productivo y generalmente consume sólo unas pocas horas (muy pocas en comparación con cualquier proyecto). Ese tiempo meses más tarde, a la hora de asumir el proyecto de nuevo, pueden ahorrar mucho más y la frustración de hacer ingeniería inversa para ver cómo se han hecho las cosas.

No se puede dar por cerrado un proyecto si no se crea la documentación exigida; es más, se debe ver si ésta se puede realizar a lo largo de la ejecución del proyecto.

Al cotizar el proyecto se deben incluir unas horas dedicadas a la documentación. No es exagerado incluir un 5% de tiempo dedicado a este trabajo.

#6 En lo posible, hay que practicar el enfoque ágil en los proyectos

En la mayoría de proyectos podemos poner en práctica todas aquellas características del desarrollo ágil que nos permite avanzar con productividad. Puesto que un proyecto será rentable si está bien cotizado y si se realiza en tiempo, entonces hay que cuidar mucho todo aquello que suponga ahorrar horas de trabajo.