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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Páginas

¿Por qué leer El Libro Negro del Programador?

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

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

Archivo

Trabajo en...

Mis novelas...