Rafa G. Blanes Blog

Los que hayan leído mi último libro ("El Arte del Emprendedor Digital"), habrán comprobado por qué es una buena estrategia desglosar la arquitectura de un proyecto software en componentes (sobre todo si el proyecto es de tamaño medio o grande y va a evolucionar mucho). De este modo (y sin entrar en demasiado detalle), la funcionalidad del sistema está ordenada en responsabilidades independientes, fácilmente localizable y modificable.

La clave está en que cada componente (llámalo módulo si quieres), sea pequeño, se encargue de algo muy concreto y específico, y que cuando haya que afrontar una funcionalidad más amplia, se pueda distribuir ésta en varios componentes que se hablan entre ellos. ¿Cómo? Pues según la tecnología y el framework de trabajo que se haya utilizado para implementar este esquema.

Hub de Libros cuenta ahora mismo con más de ochenta componentes, mientras que un proyecto sencillo en el que he trabajado recientemente, tiene ya unos treinta (muchos de ellos reutilizados de otros proyectos).

Puede parecer que se desmadra un poco la cosa cuando hablamos de decenas de módulos independientes, aunque quizá solo los que (como yo) hayan sufrido en alguna ocasión una solución monolítica con mucha funcionalidad (cientos de miles de líneas de código), podrán comprobar las bondades de esta arquitectura. En otro proyecto diferente que he dirigido en Solid Stack, actualmente cuenta ya con más de cien (y subiendo).

Si te enfrentas a un proyecto con cientos de kloc (1 kloc = mil líneas de código) y en él no hueles nada a componente o módulos independientes, malo.

Ahora bien, en todo sistema grande existe funcionalidad de alto nivel que afecta o utiliza un conjunto de funcionalidades de bajo nivel. Tenemos siempre la tentación de implementarla directamente y por separado, y aunque esté encapsulada en su propio componente, finalmente lo que tenemos es, de nuevo, un componente grande y monolítico, más difícil de cambiar, de probar y de evolucionar, y que es justo lo que queremos evitar.

Existe otro enfoque para implementar esa funcionalidad de mayor nivel basado en eventos, esto es, cuando ocurre algo en el sistema, un componente hace algo en concreto y simple, tan solo emite el evento correspondiente por si hay otra parte del sistema que necesita saber que ese evento se ha producido. La gestión de ese evento ni siquiera se tiene que producir en la misma aplicación, sino que pueden existir auténticas infraestructuras software para gestionar eventos en aplicaciones independientes. Redis, sin ir más lejos, permite un esquema de suscripción/publicación que facilita esa comunicación entre procesos para casos en los que hay que gestionar cientos o miles de eventos por segundo.

Por poner un ejemplo, si cuando un usuario se loguea en el sistema hay que guardar cierta información en el log de actividad, o lanzar un informe para su panel de control personalizado o cualquier otra cosa, todo eso no se debe implementar en el mismo componente que se encarga de la seguridad de los usuarios, éste tan solo emite un evento de tipo "users.userloggedin" (es tan solo un nombre descriptivo), y algo en alguna parte del sistema se encargará de realizar lo que haya que hacer cuando eso ocurre.

De este modo, existen componentes base que implementan funcionalidades muy canónicas, pero también, y como parte de una arquitectura bien estructurada en responsabilidades, existen otros componentes que se encargan de implementar funcionalidad de más alto nivel que afecta a grupos de componentes. ¿Cómo? Gestionando eventos y orquestando la funcionalidad de diversos componentes del primer tipo.

Rara es la funcionalidad de alto nivel que no se pueda implementar de este modo. En ocasiones, toda esa funcionalidad de ese tipo, se incluye en lo que se denomina capa de integración, e incluso se implementa bajo el concepto de flujo de trabajo o proceso de negocio.

La gestión de esos eventos no tiene por qué ser siempre síncrona (retrasando quizá la interacción del usuario con el sistema), sino que se puede plantear hacerla en segundo plano.

Con esta estrategia, todo sigue encapsulado en componentes sencillos, mientras que aquellos que se encargan de integrar funcionalidad más compleja tan solo orquestan los primeros, manteniendo incluso una implementación sencilla: ante el evento tal, hago esto y después lo otro.

Sin duda, la gestión de eventos y su orquestación son herramientas fundamentales para implementar sistemas software grandes.

En breve, voy a publicar en GitHub un proyecto en el que he ido trabajando desde hace un año y que da soporte a mi propia plataforma de publicación abierta (Hub de Libros). Se trata de un framework al que le he puesto el nombre de Mantra Framework, escrito en Node.js y que permite crear componentes altamente desacoplados para encarar proyectos grandes y que van a evolucionar mucho, tal y como describo con más detalle técnico en mi último libro (El Arte del Emprendedor Digital). Confío en basar en este framework muchos proyectos de aquí en adelante, al menos todos los basados en Node.

Tanto a un proyecto como al otro, le dedico todo el tiempo que puedo con la ayuda además de algunos colaboradores; en cualquier caso, analizando Mantra Framework, no me deja de sorprender la naturaleza de una actividad como es la programación, después de dedicarme a esto profesionalmente toda mi vida (en mis primeros escarceos tenía tan solo doce años).

Mi actividad profesional se reparte entre atender responsabilidades de desarrollo de negocio, tratar con clientes directamente, dirigir un equipo de desarrollo y también desarrollar y diseñar directamente proyectos como el anterior, además de todo lo relacionado con la publicación de mis libros (que, por el momento, son cinco técnicos y dos novelas).

Cualquiera que haya leído tan solo alguno de mis libros, sabrá que todo lo que hago está relacionado directamente con el desarrollo de software, más orientado a productos que a proyectos específicos y particulares para clientes, esto es, paso parte de mi tiempo programando, de ahí las siguientes reflexiones sobre el acto de programar y las sutilezas que esconde esta actividad y esta profesión.

Ciertamente, programar es una actividad poliédrica que se puede considerar sencilla, pero también puede ser muy compleja. Como suelo poner como ejemplo, no es lo mismo construir un chamizo que un rascacielos, como tampoco lo es construir algo pensando en que dure tan solo unas semanas a diferencia de que deba aguantar años. Y, sin embargo, paradójicamente, puedes tener éxito afrontado el software desde un lado y el otro, aunque el coste sea diferente, como veremos a continuación.

A menos que te lo propongas, cualquiera puede aprender en un videocurso de un fin de semana algunas nociones y comenzar a hacer cosas útiles, mientras que los más experimentados, no dejamos de tener nuevas percepciones y descubrir nuevos detalles que nos sorprenden en algo que llevamos haciendo años (“¡ah!, mira, nunca había reparado en esto o en las consecuencias de hacer esto otro de este modo, curioso…”)

Del mismo modo que un autor siempre escribe para contar algo que sea de utilidad a otros (entretenimiento, formación, cultura, crítica, opinión, etc), en esencia, programar consiste en resolver algún tipo de problema utilizando algún dispositivo para dar también utilidad a otros.

Esto es, salvo que programes por puro juego y divertimiento (como hago yo en ocasiones para experimentar), programamos para servir a los demás.

No importa de qué modo, en qué entornos, con qué lenguajes de programación, si dentro de una pequeña o gran empresa o como freelance, siempre programamos para ofrecerle algo a alguien. En mi opinión, esta es la actitud esencial que deberíamos tener los desarrolladores profesionales, cierta vocación de servicio de cara a nuestros clientes, usuarios de nuestros proyectos y productos y cualquiera que consuma lo que hacemos. En otras palabras, nuestro cliente final es lo más importante, mientras que en ocasiones esto se nos olvida en nuestro día a día.

Por llevarlo al terreno de lo concreto: hace años enfocaba proyectos personales centrándome en lo que a mí me gusta y que confundía con lo que podían necesitar otros. Corregí a tiempo (creo), me sumergí en toda la cultura lean (Lean Startup, de Eric Ries) y está claro que ahora, en todo lo que hago, me centro no solo en un tema que me apasiona (como todo lo relacionado con la literatura y la publicación abierta), sino que lo enfoco desde la perspectiva del usuario final o del cliente. Nos guste o no, esto afecta a nuestra forma de enfocar el software porque cambiamos la naturaleza y la prioridad de los requisitos.

Por otra parte, no solo servimos a una comunidad, sea la que sea, sino también a nuestros propios compañeros que algún día heredarán nuestro código (y lo bendecirán o se acordarán cada día de algún miembro de tu familia). Esto es, programamos también para hacerle la vida un poco más fácil a otros programadores cuando continúen con tu rabajo.

Tu misión como programador consiste en que otros entiendan tu trabajo de la forma más rápida y sencilla posible. Es más, cuanto mejor hagas esto, más podrás delegar y centrarte en aquello en lo que aportas más valor.

En cierto modo, cuanto más útil es lo que hacemos y para más personas, mejor nos irá. Por tanto, no se trata de trabajar más, de programar más y más proyectos, sino de centrarlo todo en escalar la utilidad que éstos ofrecen al mayor número de personas posible.

Programar requiere de un nivel de abstracción que, me temo, no todo el mundo es capaz de desarrollar, puesto que se deben resolver problemas traduciendo la solución usando un lenguaje de programación con sus propios recursos pero también limitaciones. Evidente, pero no lo es tanto que el código que se genera y su calidad depende mucho de ese nivel de abstracción. Observemos tan solo cómo cambia una solución implementada funcionalmente o bien escrita con un lenguaje orientado a objetos: no solo cambia el resultado de lo que se genera, sino la forma de pensar del desarrollador para enfocar el problema. Esto viene a ser algo así como un paradigma mental de trabajo que te hará resolver las cosas de un modo u otro totalmente diferente. En ocasiones, el desarrollador no es que sea malo, es que no ha cambiado aún de paradigma…

Debemos abstraer, sí, pero solo señalo que esta es una habilidad más que debemos tener los desarrolladores, y que no por eso nos convertimos en personas especiales, ni mucho menos.

La programación orientada a objetos no es un capricho académico, es una forma de pensar para traducir un problema programáticamente de un modo más sencillo, generando código con mejor diseño y más reutilizable, qué duda cabe. Sin embargo, es habitual que se utilicen clases como siemple almacén de funciones monolíticas…

Opino que programar es sencillo, cualquiera que se lo proponga puede hacerlo, pero también pienso que programar bien no es fácil, de ahí que me cause cierta sensación extraña esos cursos de dos semanas que prometen hacerte experto de la noche a la mañana. Lo sé, es un simple recurso comercial, claro está.

Programar tiene también connotaciones artísticas además de las técnicas, pensar solo con las segundas y sin las primeras conduce siempre a una mala solución. Lo digo desde la perspectiva de que para programar con éxito, necesitamos desplegar muchísima imaginación y creatividad, más allá de conocer las técnicas y buenas prácticas que sabemos que tenemos que emplear. En muchas ocasiones, la creatividad consiste en encontrar una solución sencilla a un problema que no lo es.

A diferencia de otras disciplinas, algo que también puede resultar extraño es que cuando programamos, tenemos que pensar mucho en hacerlo de un modo que podamos detectar y corregir errores más adelante. Piénsalo, el diseño del código cambia cuando pensamos en el mantenimiento del mismo, del mismo modo que se puede diseñar un coche de cara a que la reparación de sus averías sea sencilla años más tarde. Por alguna razón, esta cuestión cuesta que cale profundo en muchos desarrolladores con los que me cruzo, y si extrapolo, no tengo más remedio que pensar que es algo extendido en nuestro sector.

Inevitablemente, por mucha experiencia que tengamos, por muchas miles de líneas de código que hayamos escrito, siempre (SIEMPRE) programamos cometiendo errores, que bien son detectados por mala sintaxis en tiempo de compilación o en tiempo de ejecución en lenguajes interpretados, además de log bugs que se producirán aunque el código sea perfecto. No conozco ninguna otra actividad en la que se avance creando algo nuevo pero al mismo tiempo corrigiéndolo continuamente.

Como autor de cinco libros técnicos y dos novelas (por el momento), es evidente que una de mis actividades profesionales consiste en la publicación de libros (que para eso, además, he creado Hub de Libros).

Sin embargo, hasta ahora no he compartido nunca las razones por las que siempre recomiendo a todo el mundo (sí, a to-do-el-mun-do), que de una forma u otra, escriban, ya sea desde un diario, posts (como este) o cualquier proyecto de ficción o no ficción. Al respecto, recomiendo las lecturas de autoras como Julia Cameron y Natalie Goldberg (secreto: cada vez que comienzo un nuevo trabajo, siempre releo alguno de sus libros como forma de volver a centrarme en un proyecto literario).

Quiero compartir aquí uno de los capítulos de la guía gratuita que lancé hace poco y de título "El Manifiesto del Autor Libre: Cómo escribir un libro y publicarlo en el siglo XXI".

Ahí va.

Por qué escribir

El 80% de los estadounidenses, reconocen que en algún momento de sus vidas se han planteado la posibilidad de escribir un libro.

Casi nadie lo hace, y lo más seguro es que sea así por esa extraña «áurea» especial que le sobreponemos a autores consagrados y por desconocer cómo comenzar.

No obstante, al margen de nuestra consideración de lo que sea literatura buena o regular, las razones por las que escribir van más allá de tener éxito o no publicando una obra.

«Escribir» es un proceso mental que descarga nuestra percepción del mundo en el papel.

Existe algo mágico que sucede cada vez que ponemos por escrito nuestros pensamientos, sean en la forma de una historia o relato corto, a modo de diario o esa carta de amor que le escribimos a nuestra pareja.

Escribir supone materializar en el papel parte de la existencia que vivimos cada día (y digerir sus sinsabores y celebrar sus luces).

Si supone una de tus pasiones, dedicar media hora al día a sentarte solo contigo mismo, lápiz en mano o con el ordenador portátil sobre tu regazo, escribir es una forma magnífica de entrar fácilmente en ese estado de «fluir» con el que incluso perdemos la noción del tiempo.

Cuando escribes recuerdas que eres una persona libre: de hablar de lo que quieras, de desahogarte, de tratar de darle un significado a lo incomprensible, de digerir aquella discusión con ese ser tan querido, de tener esa fantasía con el vecino entrenador de gimnasio o la vecina enfermera e incluso de escribir caóticamente, y hasta con faltas de ortografía y de puntuación, cualquier cosa que se te ocurra.

Comprende la vida y tus vivencias… escribiendo.

Elimina el rencor externalizándolo sobre le papel.

Celebra la vida contando ese acontecimiento tan feliz en una nueva entrada en tu diario.

No hay nadie que te juzgue ni reglas: tan solo estás tú y el papel.

De ese modo, algo tan aparentemente inofensivo como tu propio diario, se convierte en un compañero fiel al que acudes para contarle «tus cosas», cómo fue el día, tus preocupaciones más profundas o hasta desarrollas en él esas fantasías tan libertinas como necesarias.

En cierto modo, cuando lees, de algún modo te sumerges en la mente del escritor; cuando escribes, plasmas en palabras tu mundo interior.

Si a veces todo nos parece caótico, cuando escribes tú creas tu propio mundo hecho a tu medida sin rendirle cuentas a nadie, en la forma de escuelas de magia, historias de amor, distopías o contando las hazañas de unos superhéroes o detectives sagaces.

La vida en sociedad nos impone límites necesarios, pero en la escritura, no hay límites.

Comienza el día liberando tu mente creativa escribiendo unas cuantas páginas al azar, de lo que sea, tan solo tus pensamientos erráticos mientras tu mente se despierta (Julia Cameron, autora de «El camino del escritor», libro que recomiendo, las llama «páginas matutinas»).

Termina la noche volviendo a esas páginas para destacar en palabras los momentos agradables, los nuevos problemas o acontecimientos que te parezcan importantes, y comprobarás que sientes cierta liberación al haber expresado de algún modo todo ese mundo mental de tu interior.

Recupera esa bella costumbre de redactar un correo (en papel o electrónico) para mantenerte en contacto con amigos que ahora viven lejos.

Escribe como terapia sobre cualquier asunto que te inquiete. También escribe para desarrollar esas ideas semilla que intuyes descubriendo que tan pronto como te obligas a ponerlas por escrito, lo difuso y evanescente se transforma en algo más concreto y factible, definido.

Conócete mejor a ti mismo, expulsando de tu interior con la forma de palabras todo aquello que se cruza por tu mente y tu vida.

Las razones para escribir son muchas, tan solo tienes que elegir de entre todas ellas aquellas que resuenen mejor en ti y, quizá, darle una oportunidad al resto.

Escribir es la mejor herramienta de desarrollo personal que conozco.

Del mismo modo que un paseo errático y sin dirección no sabemos a dónde nos conducirá, escribir, sin duda, te llevará a lugares inesperados y te puedo asegurar que sorprendentes.

Mientras tanto, ese par de golondrinas que cada tarde bailan frente al ventanal de mi salón, ignoran que su bello cortejo con esos rápidos movimientos, fugaces, únicos, irrepetibles, los he captado para siempre en estas palabras.

PD: Este artículo es uno de los capítulos de la guía gratuita "El Manifiesto del Autor Libre", disponible desde la sección de recursos y también disponible en Amazon.

Cómo escribir un libro y publicarlo en el siglo XXI

Acabo de publicar una guía (gratuita) desde Hub de Libros (Plataforma Editorial de Publicación Abierta) en donde describo cómo los modelos con los que se han estado realizando muchas actividades hasta hace unos años, han cambiado radicalmente gracias a la tecnología.

La escritura y la publicación, también, existiendo más oportunidades que nunca para todo el mundo que quiera escribir y publicar.

No me gustan los términos autopublicado ni autor independiente, en un momento en el que grandes y conocidos autores se pasan a este modelo de publicación que ofrece más ventajas que inconvenientes.

De ahí que me guste más el concepto de autor libre.

En esta guía puedes conocer los pasos que tienes que dar para publicar de forma libre, sus ventajas frente a modelos antiguos de publicación (perdirle permiso a editoriales de toda la vida) así como algunos consejos para escribir incluso en mitad de una vida muy ajetreada.

La puedes descargar desde https://www.hubdelibros.com/recursos o también obtenerla en Amazon (esta última opción tiene el precio mínimo ya que en Amazon no se puede indicar el precio de una obra como gratis directamente).

A continuación, incluyo el capítulo de introducción.

El Manifiesto del Autor Libre: Cómo escribir un libro y publicarlo en el siglo XXI. Capítulo de Introducción

¿Qué pasaría si te dijera que puedes escribir un libro (incluso en medio de una vida muy ocupada) y publicarlo para que lo lean en cualquier parte del mundo y además recibir ingresos a partir de él puntualmente cada mes? Esto es una realidad.

Hola, mi nombre es Rafael Gómez Blanes y soy el CEO de Hub de Libros — Plataforma Editorial de Publicación Abierta.

En las siguientes páginas te vamos a mostrar cómo puedes concebir un proyecto literario, ponerlo en marcha (incluso si tienes una vida muy ajetreada) y publicarlo, esto es, ponerlo a disposición de millones de lectores, tal y como he hecho yo.

Pero antes, te voy a hablar un poco sobre mí.

Mi actividad como autor comenzó en el año 2014. Lancé entonces un libro que habla acerca de mi actividad como ingeniero software («El Libro Negro del Programador»). Lo que comencé casi de forma anecdótica en aquel primer libro, constituye hoy día una de mis actividades profesionales.

(Algunos de mis libros disponibles en Amazon y Google Play)

En el momento de escribir esto, cuento con cinco libros de carácter técnico y dos novelas publicadas.

Cada día, y digo, cada día, y desde hace años, algunos de mis títulos se venden en alguna parte del mundo: España, Estados Unidos, México, Chile, Canadá, etc. y hasta Japón, a pesar de que solo uno de ellos está traducido al inglés por el momento.

Gracias a esa experiencia como autor, hemos creado Hub de Libros para ayudar a muchos otros a recorrer el mismo camino que yo he transitado estos años.

Sostengo que «publicar» es un Derecho, al igual que Escribir, como diría Julia Cameron.

Por si aún no te habías dado cuenta, la publicación se ha «democratizado».

En estos años, un factor importante ha venido a modificar la forma en la que los lectores leen, consumen y adquieren libros, y también el modo en que los autores escriben y publican, y este factor no es otro que la tecnología. Esto es: «las editoriales necesitan de los autores, pero éstos ya no necesitan de aquellas».

Este cambio no es ni bueno ni malo, tan solo ciertos modelos de negocio evolucionan, surgen nuevos y otros mueren.

Pero para los autores, esto sí que es una gran noticia.

Lejos quedan los tiempos en los que necesitábamos el permiso de una compañía (que llamaremos «editorial tradicional») para indicarnos y certificar si nuestro trabajo es bueno o no. ¿Para qué están los lectores, si no?

La única medida del éxito de tu obra es la opinión de los lectores. Punto. Esto es una declaración de principios en Hub de Libros.

Las «editoriales tradicionales» tienen un gran papel en la industria del libro y la cultura, qué duda cabe, pero ya no es una exigencia el tener que pasar por los filtros comerciales o de otro tipo para que tu obra llegue al público más amplio posible.

La tecnología ha permitido un cambio de modelo en esta actividad, del mismo modo que ha irrumpido en todos los ámbitos de la economía, y, ¿sabes qué? Lo va a seguir haciendo queramos o no.

Como escritores, aprovechémoslo.

Nos guste o no, la tecnología ha venido para quedarse y transformar totalmente todas las áreas económicas de nuestra vida en sociedad.

La cultura (y la publicación), también.

Algunos datos:

● Los autores más vendidos en la mayor librería del mundo (Amazon) son autopublicados. Reconozco que no me gusta el término «autopublicado», pero de ello hablaremos en las siguientes páginas.

● El libro electrónico sigue su imparable crecimiento (podemos leer desde eReaders, el teléfono móvil, una tablet, etc., desde cualquier dispositivo electrónico), no solo en papel. Si lo piensas, es la consecuencia natural y lógica.

● En el modo de escribir y de encontrar «betareaders» también tenemos más posibilidades que nunca (con servicios como Leanpub o Wattpad y, claro está, Hub de Libros).

Yo, sin ir más lejos, como lector, y tan solo revisando lo que he leído en lo que va de año, puedo decir que más de la mitad han sido autores que no tienen detrás ningún sello editorial (ni grande ni pequeño), superventas como Raimón Samsó, Mario Escobar y Fernando Gamboa, por poner unos ejemplos. En mi opinión, muy buenos escritores.

En esta breve guía te voy a introducir en el mundo de la publicación libre para que sepas qué pasos tienes que dar para que tu libro pueda ser leído en gran parte del mundo sin que una compañía tradicional de «modelo antiguo» adquiera tus derechos de autor (tu trabajo) a precio de saldo.

No me gustan los términos «indies» ni «autopublicación», utilizados a menudo de forma peyorativa por ese sector industrial cuyo modelo de negocio (si no cambia en los próximos años) se va a ver muy amenazado, de modo que en el contexto de este trabajo, vamos a llamar a los autores que controlan todo lo relacionado con su trabajo como «autores libres».

Me gusta considerarme un «autor libre»: yo controlo todo el proceso de escritura de mis libros así como de su publicación. Y lo hago con una calidad que, en mi opinión, es extraordinaria (algunos de los pasos de generación de un libro no los hago yo, sino que delego en gente más experta).

Y de todo eso es precisamente de lo que te quiero hablar en esta guía, porque, además, para eso he fundado Hub de Libros.

Yo me considero, como digo, un «autor libre» con la suerte de que mis obras se venden cada día y ayudan a muchos lectores. Pero como yo, hay miles más que han dado el paso y cientos de miles más que aún no saben cómo empezar. De ahí esta guía gratuita editada desde Hub de Libros.

Pienso que debemos dedicar parte de nuestro tiempo a ayudar a los demás y que esto lo podemos hacer de muy diversas formas. Es más, cuanto más sepamos ayudar a otros, en el sentido que sea, seguramente mejor nos irán las cosas y hasta puede que mejor nos sintamos con nosotros mismos. Por lo menos yo pienso así.

Para ello, hay muchas formas, tantas como se te ocurran: colaborando, escribiendo posts en tu propio blog, participando en proyectos colaborativos y desinteresados en GitHub, realizando mentorías o incluso escribiendo libros cuando crees que tienes algo que aportar a tu comunidad.

También pienso lo siguiente: Si algo me ha funcionado a mí, ¿por qué no contarlo para que otros se beneficien?

Por esa razón fundé Hub de Libros, para que todos esos autores que escriben tengan fácil acceso al mundo de la publicación y que puedan difundir su trabajo por casi todo el planeta y no tengan los obstáculos que yo tuve (y que superé dolorosamente con mucha prueba y error) desde el año 2012, porque sé que muchos se quedan por el camino provocando que, quizá, información o conocimiento muy valisosos queden olvidados en el fondo de un cajón, o porque creen aún que para contar algo y empaquetarlo en un formato libro se necesita del permiso de una editorial de toda la vida (como diría Julia Cameron), en el siglo de la tecnología y de modelos disruptivos como Uber, Etsy, Airbnb y muchos otros.

Del mismo modo, describir a nivel técnico cómo he enfocado un proyecto software tan ambicioso como complejo como Hub de Libros, me ha llevado a trabajar en los últimos meses en El Arte del Emprendedor Digital, mi nuevo libro con el que espero ayudar y animar a toda esa comunidad relacionada con la tecnología y con ganas e inquietud de emprender o de lanzar nuevos proyectos.

Parece ser que vivimos con una dinámica en la que todo el mundo está demasiado ocupado, desde que nos levantamos hasta que nos acostamos.

Pero yo me pregunto lo siguiente: ¿Ocupados en qué?

Para mí la primera medida del éxito consiste en permanecer ocupados, al menos la mayor parte del tiempo, en aquello que nos interesa y en la dirección de nuestras metas a largo plazo y, por supuesto, mantener una vida equilibrada en todas sus áreas.

Sin embargo, he descubierto todos estos años, cruzándome con CEOs, CTOs, gerentes y muchos otros desarrolladores, que se confunde demasiado el estar ocupado con trabajar productivamente y, de ahí, a un paso tenemos una vida llena de estrés y sin saber cómo mejorar.

Esto es, no se trata de trabajar más horas sino de trabajar mejor.

Desarrollar un proyecto como Hub de Libros (y otros anteriores junto con aquellos en los que participo actualmente), consiste también en cierta forma de enfocar el trabajo y de hasta mantener ciertas habilidades de desarrollo personal.

Por esa razón, en El Arte del Emprendedor Digital no solo describo los aspectos técnicos más relevantes de algunos de mis proyectos en marcha, sino también de todas esas técnicas y habilidades que a mí me han servido para poder concentrarme en un trabajo tantas horas y durante muchos meses compatibilizándolo con el resto de mis responsabilidades: desde kaizen hasta las microtareas, la importancia de conseguir concentración, fluir y hasta cómo gestionar las dudas, y un largo etcétera.

Inevitablemente, este nuevo libro tiene, por tanto, un carácter algo personal e intimista, que no me importa compartir puesto que pienso que su contenido puede ser de mucha utilidad a tantas personas que quieren avanzar en sus proyectos o que quieren emprender con la mayor probabilidad de éxito, y del mismo modo, me he tomado la libertad de describir en el mismo libro aspectos técnicos (muy técnicos, de hecho) junto con herramientas de desarrollo personal, porque, en definitiva, por muy buen técnico que se sea, por muy buena la idea que quieres implementar, si no dominas estas últimas estrategias de carácter personal, el camino será mucho más difícil, si es que no se abandona nada más dar los primeros pasos.

Yo abandoné en algunas ocasiones, fracasé en otras, pero también he tenido éxito en muchos otros proyectos, aunque ahora comprendo que lo primero no es más que una fuente de aprendizaje para seguir avanzando.

El Arte del Emprendedor Digital me lo prologa nada más y nada menos que José Murillo, compañero durante algunos años en mi primera etapa laboral y quien después trabajó para Microsoft durante más de quince y que desde hace dos años es el CEO de su propia compañía (Smart IoT Labs).

No sé si el movimiento startup y todo lo relacionado con el emprendimiento (tan de moda últimamente) serán o no el corazón de la nueva economía a la que nos dirigimos, pero de lo que sí estoy seguro es de que aquellos que trabajamos con la tecnología lo tenemos más sencillo para lanzar proyectos que aquellos que trabajan en otros sectores.

En El Arte del Emprendedor Digital describo cómo he afrontado Hub de Libros y cómo se plantea la evolución de un proyecto con metodología lean, junto con los elementos más importantes y paradigmáticos que debe cumplir un proyecto software que va a cambiar continuamente y que desde su comienzo, ni siquiera tenemos claro cómo será esa evolución, entre otros muchos temas.

Confío en que este nuevo trabajo que he realizado con tanta ilusión (y esfuerzo), y que es de los primeros títulos editados por mi propia plataforma editorial, sea de utilidad tanto o más como mis anteriores libros.

Recientemente he publicado en un único ebook los tres libros técnicos que he escrito hasta el momento, dándole el nombre de La Trilogía del Programador Profesional.

En cierto modo, tanto El Libro Negro del Programador, El Libro Práctico del Programador Ágil y The Coder Habits, forman una unidad en su conjunto aportando tanto esa meta visión acerca de nuestra profesión como desarrolladores de software, pasando por las buenas prácticas técnicas y hábitos como programadores profesionales.

Es difícil encontrar gran parte de ese conocimiento, menos aún en castellano, extraído de mi propia experiencia, reunido en un único trabajo.

Me ha parecido práctico reunir los tres libros en uno solo para así facilitar su lectura y adquisición.

He añadido, además, una introducción a este nuevo pack después de lanzar uno de mis proyectos más ambiciosos.

Desde hace unas semanas ya lancé oficialmente un proyecto en el que he trabajado con mucha ilusión y que en algunos aspectos ha sido todo un reto técnico. Toca aquí más hablar de estas cuestiones técnicas que del proyecto en sí. Pero antes, un poco de historia personal...

En 2014 publiqué mi primer libro (El Libro Negro del Programador) y desde entonces no he parado de tener siempre un proyecto literario en marcha, de tipo técnico, novela o relatos cortos. ¿El resultado? Seis libros, cuatro relacionados con el desarrollo de software profesional y dos novelas (éstas bajo el seudónimo de G. Blanes), perto también conocer con detalle todo lo relacionado con la publicación independiente (o indie) y hasta considerar mi trabajo como escritor como un área más de mi profesión.

Para los que aún no lo sepan, ya no hace falta que una editorial "de toda la vida" te elija para que puedas publicar tu libro, y mucho menos venderlo en cualquier parte del mundo. Internet ha permitido explorar miles de nuevos modelos de negocio y el mundo editorial no puede quedarse al margen de ello. Esto es, en cierto modo, se ha democratizado la posibilidad de publicar (ya no se necesita el permiso de nadie para hacerlo).

Me sorprende (y digo esto a modo de reflexión personal), esa extraña áurea que rodea la imagen de un "escritor", y que algunos se sientan bendecidos y pontificados por una mano mágica que los diferencia del resto de los mortales, algo que no ocurre en otras profesiones. Es cierto que siempre habrá buenos pintores y malos, buenos programadores y peores, y por lo tanto, también excelentes escritores que ganan El Nobel y muchos otros aficionados. Sin embargo, hay espacio para todo el mundo que tenga inquietudes creativas, en cualquier área. No en vano, cuántos artistas consagrados hoy en día fueron rechazados en su época, como pareciendo que hace falta morir para que valoren tu trabajo...

Autores cuyas obras nunca habrían visto la luz por no encajar quizá en los intereses comerciales o de nicho de las editoriales tradicionales, pueden ahora dar a conocer su trabajo gracias a la tecnología. Otros, ya consagrados, se pasan a la publicación independiente porque genera más libertad y mayores royalties, qué duda cabe.

No hablo solo de autores de "literatura", sino de cualquier tipo y  género: de desarrollo personal, técnicos, etc. Es más, me atrevo a decir que en nuestra profesión, se echa en falta más y mejor literatura técnica en castellano, quizá porque muchos desarrolladores no exploran ese camino.

No me gusta la expresión publicación independiente, que es tanto como decir, si existiera alguna similitud con otras actividades, escultor independiente, pintor independiente o hasta programador independiente. Suena raro, ¿verdad? ¿Acaso hay que etiquetar de algún modo el hecho de que tú seas el responsable de tu publicación a diferencia de que exista cierta entidad que te "da permiso" para dar a conocer tu trabajo?

Si bien hace diez años quien no conseguía que le publicaran terminaba "autopublicándose", y el término "independiente" se asociaba más a aquellos materiales que no encajaban en las tendencias más clásicas y comerciales de las editoriales, hoy día todo esto ha cambiado radicalmente.

Es más, hoy día la tendencia comienza a ser ésta, incluso autores que vienen "del otro lado", como Matilde Asensi y Raimón Samsó, pasan parte o todo su trabajo a este modelo. ¿Por qué? Por la misma razón por la que Airbnb le permite a los dueños de apartamentos rentabilizarlos mejor o aquel proveedor de suministros decide abrir una tienda en Amazon y llegar a más clientes: porque la tecnología lo permite a un coste mínimo y de escala y porque así tienes el control total de tu activo (sean productos o servicios).

¿Y qué pasa con la labor insustituible que es necesaria para generar un libro de calidad? Estoy hablando de revisar, corregir, diseñar la portada, maquetar el contenido, la promoción, el markenting, etc. Todo eso, qué duda cabe, un trabajo duro que hacen las editoriales, ahora se puede subcontratar, si quieres, a quien quieras y cuando quieras. De esto hablaremos un poco más adelante.

Esto es, publicar de forma independiente consiste básicamente en que tú haces tu trabajo de escribir, pero también te encargas de obtener la portada, maquetar tu libro, revisarlo hasta la saciedad y publicarlo directamente en plataformas como Amazon, Google Play, Kobo, etc. O bien le encargas a otros profesionales ese trabajo por un precio razonable. En cualquier caso, tú tienes la libertad y el control (y los derechos de autor) sobre tu obra, y que sean los lectores únicamente los que tengan la capacidad de juzgarla.

Porque esto es lo que yo pienso y creo: Igual que leer es un Derecho, opino que Escribir también lo es (como dirían Julia Cameron en su libro El Camino del Escritor o Natalie Goldberg), de modo que nadie te puede impedir hacerlo, tanto si consigues rentabilizarlo como si no, de ahí que haya creado Hub de Libros como Plataforma Editorial de Publicación Abierta.

Leí recientemente que más de un ochenta por cierto de la población estadounidense ha deseado en algún momento de su vida escribir un libro. La mayoría no lo hace. 

La diferencia es que ahora es posible a menos que te lo propongas.

¿Y qué pasa con la calidad? Sí, así también cualquiera puede publicar un bodrio (que no va a ser leido por casi nadie, por cierto) o bien una auténtica joya. Pero también puedes mejorar tu texto en cualquier momento (como hago yo cada vez regularmente sobre mis libros), cambiarles el precio, etc.

En cualquier caso, la última palabra la tienen los lectores, solo ellos van a indicar la valoración sobre tu trabajo. 

Pues bien, detrás de toda esta historia y de cierta inquietud personal al afirmar que Escribir es un Derecho que tenemos, está Hub de Libros y la Plataforma Editorial de Publicación Abierta. Es un site donde los lectores pueden encontrar nuevos contenidos pero, sobre todo, nuevos autores y los escritores pueden crearse su propio perfil y publicitar sus trabajos. 

He creado Hub de Libros para que los autores que quieran publicar, lo puedan hacer sin los problemas técnicos que yo tuve en su momento y que fui superando con mucho esfuerzo, prueba y error.

También creo en la economía gig, en la que cada vez más y más profesionales pueden ofrecer sus servicios a cualquier cliente de cualquier parte del mundo, como se hace a través de Fiverr y muchos otros portales. Para ello Hub de Libros dispone de una serie de gigs o servicios que cualquiera puede contratar relacionados con todo lo necesario en el proceso de creación de un libro.

Hub de Libros también es un reto técnico, y me propongo hablar de todas las estrategias que he empleado en él y que permiten que sea una plataforma diseñada para crecer y ser evolucionada fácilmente mediante Mantra Framework, otro proyecto propio en NodeJS en el que comencé a trabajar hace ya dos años en base a mi experiencia de haber lanzado proyectos muy escalables (que soportan un gran número de usuarios y manejan un volumen de datos muy alto), para lo cual hacen falta estrategias de diseño y arquitectura que nada tienen que ver con una aplicación de tamaño pequeño o mediano.

Es cierto que existen otros frameworks muy maduros y con una buena acogida, como NestJS, pero ciertas consideraciones técnicas a largo plazo me llevaron a concretar el desarrollo de Hub de Libros en un framework propio fácilmente evolucionable. En los siguientes puntos entendrás por qué.

Estas son varias de las claves técnicas sobre las que se asienta a nivel de software Hub de Libros:

Ahora que en mi país y muchos otros se imponen medidas drásticas para frenar el COVID-19, muchos empleados están obligados a trabajar desde sus casas por primera vez en sus vidas. Algunos estarán aterrados (no por el virus, sino por trabajar en sus casas), y otros sentirán que están ante una gran oportunidad.

Lejos de lo que pueda parecer, teletrabajar puede suponer todo un reto no solo por cuestiones de conciliar la vida familiar y profesional: teletrabajar es algo que va mucho más allá que cambiar el lugar donde realizas las tareas para tu compañía.

Llevo trabajando en remoto varios días a la semana desde hace años, desde el momento que concebí que mis responsabilidades laborales eran compatibles perfectamente sin necesidad de estar presencialmente en una oficina. Hasta ahora, puedo decir que ha sido una de las mejores decisiones de mi vida. Sin embargo, tengo que reconocer los cambios profundos que esta forma de encarar el trabajo, impactan en la forma de organizarlo (para mí y para el resto de mis compañeros).

Puedo afirmar que en mi caso soy más productivo, me siento tanto o más a gusto en mi despacho y el hecho de no estar atado necesariamente a un horario, me permite emplazar las tareas de un modo más ágil y eficiente en el día a día, pero para ello, es todo un reto saber desconectar, al tiempo que hace falta una gran autodisciplina.

Puede que ahora muchas empresas descubran que ofrecer a sus empleados esta opción, supone un ahorro de costes. Por su parte, puede que los trabajadores también descubran que pueden ahorrar en desplazamientos, trabajar mejor y hasta ser más productivos, etc. Pero también puede ocurrir todo lo contrario.

Teletrabajar no es sencillo, no es para todo el mundo (ni para todas las compañías, obviamente, aunque el trabajo se realice a través de un ordenador).

Trabajar remotamente supone utilizar un paradigma laboral (y mental) diferente, así como de una autodisciplina que hace falta desarrollar y que no todo el mundo está dispuesto a pagar el precio para adquirir.

Teletrabajar supone, además, organizar el trabajo de un modo diferente, de modo que implica cambios en la forma de actuar de los managers y responsables y también de los equipos de trabajo.

Esta forma de afrontar el trabajo es incompatible con aquellos perfiles que necesitan que se les diga qué hacer en todo momento o que trabajan y se implican más cuando "el jefe" está presente, es decir, el teletrabajo no funciona con aquellas personas que:

• No saben organizarse a sí mismas su jornada laboral, preguntándose continuamente eso de ¿y ahora qué hago?
• No se sienten implicadas en la organización para la que trabajan.
• Hacen lo mínimo para salir adelante (y, curiosamente, hacen más cuando hay más presión sobre ellas).

Del mismo modo, si una compañía (y hablo de las tecnológicas) cree que su actividad se puede descomponer en una serie de tareas que alguien las realiza, una tras la otra, puede que se lleve una gran decepción.

El teletrabajo es para compañías que confían en personas autoresponsables y empleados que fomentan la buena realización de las tareas. Trabajar en remoto no tiene nada que ver con el esquema tradicional de "jefe dice qué hacer, y empleado lo hace y punto".

Cada vez más, las empresas que tienen más éxito son aquellas que confían en sus empleados: para crear nuevos productos, para proponer mejoras en cualquier ámbito de la organización, para hacer siempre lo que hay que hacer en el momento adecuado. Y desde el otro lado también: empleados autoresponsables y proactivos, implicados en el proyecto que supone la organización para la que trabajan.

Esto es, trabajar en remoto exige un paradigma laboral para el que la mayoría de la gente (y empresas) no está preparada (aún).

No hablo de tener en casa las condiciones adecuadas para poder trabajar, sino de una actitud mental difícil de encontrar en una cultura laboral en donde muchos miran la hora deseando salir de la oficina por falta de motivación (o porque consideran el trabajo un simple medio de ganarse la vida, lo que se suele llamar un "trabajo nutricional").

Mandar a la gente a casa con tanta precipitación (como ha pasado estos días) sin haberles preparado para teletrabajar y sin haber incluso puesto en marcha la metodología necesaria para afrontar tareas en grupo no presencialmente, puede que les lleve a muchos una gran sorpresa.

Otros, como yo hace unos años, descubrirán encantados que esta opción supone una serie de ventajas difíciles de imaginar.

Si tú gestionas tu tiempo..., gestionas tu vida. De eso va el teletrabajo en realidad, pero para ello, tu grado de implicación en tu compañía tiene que ser muy alto.

Muchas de las tareas laborales que realizamos los profesionales de IT, pueden ser realizadas en cualquier momento del día, entonces... ¿por qué ceñirse a un horario estricto? Esto ocurre así porque hasta hace bien poco la única manera de estructurar el trabajo era (y sigue siendo), de ese modo.

Las tareas que exigen creatividad y un alto grado de concentración, como desarrollar software, diseñar, escribir, etc., no pueden estar ligadas a un horario estricto; esto va en contra de su naturaleza. Se podrían hacer mejor, y con mejores resultados, si las realizamos en el momento del día que sea más adecuado para nosotros. Esto no es hacerlas cuando nos dé la gana, sino ser autoresponsables y hacerlas en cualquier caso, pero no necesariamente cuando otra persona nos lo impone.

Yo sostengo que hasta ahora no se ha teletrabajado más por una falta de confianza entre los responsables y sus equipos, y también sostengo que las compañías que superan esa barrera, son las de más éxito, porque supone que integran a personas más motivadas y autoresponsables con su actividad. Esta autoresponsabilidad consiste en que el manager saber que el equipo se responsabiliza de su trabajo y no necesita ejercer de supervisor: los resultados hablan por sí mismos.

Recuerdo la ley de parkinson: una tarea se expande tanto como el tiempo del que dispones de su realización, de ahí la necesidad de que un teletrabajador sea responsable, ya que el trabajo del manager no consiste en vigilar el patio de un colegio, sino en comprobar que las cosas se hacen bien, con calidad y en tiempo.

Es una cuestión de actitud y motivacioń: no tienen nada que ver las actitudes de una persona que "trabaja por dinero" (totalmente legítimo), que aquella que siente un significado por las horas que pasa prestando sus servicios a su organización. La primera mirará el reloj, se implicará lo mínimo, la segunda será proactiva y su trabajo será de mayor calidad.

Nunca he sido responsable de recursos humanos, pero sí he visto que los mejores profesionales con los que me he cruzado hablan de sus empresas con orgullo, los mismo para los que si hay que trabajar puntualmente un fin de semana no ponen pega porque saben que están apoyando no un trabajo, sino una causa de la que se sienten comprometidos y orgullosos.

El reto, por tanto, no es para el empleado que de un día para otro tiene que aprender a teletrabajar, sino para la empresa que tiene que crear un proyecto motivador a largo plazo que haga que la gente dé lo mejor de sí.

Y lo mejor no son eternas horas de trabajo, al contrario, sino su imaginación, ideas y creatividad. El esfuerzo sin un ideal detrás, sin una motivación, es... eso, esfuerzo; por el contrario, con una gran motivación personal y profesional, las horas trabajando dejan de ser esfuerzo.

En cualquier caso, después de estas reflexiones, con las que ya te habrás dado cuenta de que teletrabajar es más que desplazar tu oficina a tu casa y tiene más que ver con otra forma de entender el trabajo, indico a continuación algunos consejos prácticos:

• Encuentra un lugar de la casa donde te sientas realmente a gusto.
• Habla con la familia, indícales que mientras estés en él, que intenten interrumpirte lo mínimo posible.
• Vístete con ropa de trabajo: parece una estupidez, pero hemos acostumbrado a la mente de que en pijama... dormimos, con esa otra ropa, entramos en modo de trabajo.
• Sigue manteniendo un horario estructurado, sea el que sea, pero estructurado a fin de al cabo.
• Empieza cada día con las tareas organizadas el día anterior y planifica su realización según los momentos de mejor conciliación con la familia.
• Evita el exceso de llamadas con el resto de compañeros; para ello, emplázalos a reuniones cortas en horas concretas para tratar exactamente los asuntos en cuestión.
• Utiliza herramientas ágiles de comunicación, pero no permitas que estén siempre activas de modo que te interrumpan continuamente.
• Mientras trabajes, pues eso, trabaja, olvida las redes sociales y cualquier tipo de distracción.
• Aunque esto también vale para trabajar en la oficina, trabaja lo más concentrado posible, y descubrirás mágicamente que las tareas se terminan antes.
• Ve al grano y no pierdas el tiempo. Varios minutos en esto y aquello, hoy y mañana y pasado mañana, se convierten en muchas horas a lo largo del mes (tiempo que le quitas a otras actividades de tu vida).

No es algo difícil de alcanzar, compañías como Hotjar tienen trabajadores en remoto en treinta países diferentes y siguen adelante, publicando además su experiencia al respecto, y, quizá, ojalá, este sea el futuro de las empresas de tecnología y startups.

Kaizen es un concepto japonés que viene a traducirse por “pequeño cambio” o “pequeña mejora” que en ese país es toda una filosofía de trabajo que explica cómo una nación próspera devastada por la Segunda Guerra Mundial, volvió a emerger a partir de los años sesenta hasta convertirse de nuevo en otra potencia económica y tecnológica.

Kaizen es también una filosofía de vida y una técnica maravillosa y sencilla de vencer la procrastinación, reducir lo complejo en pequeños pasos sencillos y de mejorar en cualquier aspecto que te propongas. 

En ingeniería del software se habla del concepto de mejora continua (continuous improvement), que puede ser nuestra particular aplicación práctica de Kaizen; pero, ¿mejorar en qué? ¿para qué?, y sobre todo, ¿cómo?

Puedo decir que practico Kaizen desde hace años; sin ir más lejos, cada capítulo o sección de los libros que publico los encaro en ocasiones a ratos de veinte minutos, en otras, reviso y corrijo aquel texto que escribí hace ya un mes, y vuelvo a revisar y mejorar y ampliar el contenido en un sinfín de tareas e iteraciones que suelo anotar en aplicaciones como Wunderlist o Evernote.

Aunque considero que escribo y comparto experiencia en mis libros y artículos como parte de mi trabajo profesional, raro es el día o la semana en que puedo dedicarme a ello durante varias horas seguidas, sin interrupciones, de ahí que me obligo a mí mismo a identificar esas tareas de modo que sean cortas de realizar. Precisamente por su tamaño y poca complejidad, las hago con facilidad y sin demasiado esfuerzo, y las realizo, quiero decir, que termino haciéndolas antes que tarde. Así es como encaro la mayor parte del trabajo de redacción de un nuevo libro para compaginarlo con el resto de mis responsabilidades profesionales.

¿Y por qué termino realizando esas minitareas? No es porque trabaje más que nadie, de ningún modo, sino que sé que la mayoría me van a suponer poco tiempo y casi siempre son más o menos sencillas de implementar, esto es, son pequeñas mejoras y pequeños avances en un proyecto como escribir este artículo: Kaizen en estado puro.

Si llevas años sin correr, no te atrevas a tratar de salir a hacer cuatro kilómetros el primer día. Mejor hoy camina un rato, mañana otro, la semana que viene camina pero a un ritmo algo mayor, en dos semanas ya puedes trotar y en un mes, tan solo introduciendo pequeños cambios en esa nueva rutina básica y simple que te estás construyendo, corre por fin unos cuantos cientos de metros. Pequeños cambios y mejoras para abordar algo más complejo (como poder correr cinco kilómetros seguidos sin morirte en el intento).

Te preguntarás qué tiene esto que ver con desarrollar software...

Kaizen funciona porque nos permite evitar el boicot de nuestra propia mente cuando la enfrentamos a trabajos complejos, pesados y que requieren un gran esfuerzo (o que tampoco nos estimulan y motivan especialmente). Recuerda, nuestro cerebro está diseñado para mantenermos en una cálida zona de confort (seguridad) y le asusta cualquier cosa que nos saque de ella, aunque sabemos que de un modo u otro, aquello que queremos conseguir (esa tarea compleja) requerirá salir de esa zona de confort en forma de esfuerzo y quebraderos de cabeza.

Con Kaizen evitamos ese mecanismo primitivo de autoprotección que nos impide en muchas ocasiones mejorar (o avanzar en nuestros proyectos), y me atrevo a decir que también en nuestros propósitos vitales.

¿Acaso tiene que ver Kaizen con programar o modernizar esa aplicación heredada monolítica, fea y mal desarrollada, o avanzar en un proyecto personal para el que apenas tienes tiempo o escribir esos tests que se resisten?

Pues sí, y mucho, porque si afrontamos nuestro trabajo de ese modo, aunque parezcan tareas pequeñas, llegaremos más lejos, y lo podemos hacer practicando Kaizen: paso a paso, pequeña tarea más pequeña tarea, una minúscula mejora aquí y otra allá y, cuando nos demos cuenta, después de acumular cientos de pequeñas mejoras (o miles), nuestra aplicación comienza a brillar, a contar con un mejor diseño y a estar mejor estructurada.

Además, si trabajas en una aplicación compleja y frágil, introducir pequeños cambios nos dará la seguridad de que en caso de efectos secundarios, los detectaremos con rapidez y también será más sencillo resolverlos.

No es trabajar menos horas, sino hacerlo de manera más descansada y avanzando con más seguridad. Tan pronto como tengas que realizar algo que parece "grande", complicado y hasta pesado, tan solo tienes que descomponerlo en pequeñas tareas, cuanto más pequeñas mejor, darte una fecha e ir terminándolas una detrás de la otra.

Desarrollar buen software requiere de cuidar de muchos detalles: dos o tres pequeñas mejoras hoy, suponen decenas a lo largo tan solo de un mes y quizá miles a lo largo de un proyecto cualquiera.

Con el tiempo, me atrevo a decir que hasta desarrollas cierta "mente Kaizen", y comienzas a tirar de tu Wunderlist continuamente porque ves oportunidades de pulir esto y lo otro por todos lados.

Por último, sospecho que se es mucho más productivo afrontar el trabajo mediante periodos cortos de concentración (tal y como sugiere la técnica del pomodoro) que sentarte una mañana entera y no despegar los ojos de la pantalla, más aún cuando tienes que atender, como es mi caso, tareas de muy distinta naturaleza.

Un libro que me gustó mucho sobre Kaizen: "El método Kaizen", de Robert Maurer.

Este podría ser uno de los capítulos extra de El Libro Negro del Programador. En demasiadas ocasiones veo la siguiente dinámica de trabajo (en la que yo también, por supuesto, he caído muchas veces, aunque ya menos): trabajamos en un proyecto y nuestra principal obsesión consiste en añadir funcionalidad, nuevas características, ahora esto, ahora aquello, y así durante meses cuando creemos que estamos avanzando.

Puesto que ese es seguramente el aspecto más atractivo como desarrolladores de software, eso mismo es entonces lo que hacemos, y disfrutamos viendo crecer la aplicación con nuevas características, para nuestro gozo, disfrute y satisfacción. Por el momento, los desarrolladores contentos, el negocio y el cliente, también.

Todo "parece" ir sobre ruedas, como esas relaciones que aparentan ser la pareja perfecta pero que luego en la intimidad se tiran los trastos a la cabeza, esto es, algo hay podrido en alguna parte que terminará por estallar el momento menos pensado.

Volviendo al proyecto software, puede que no te hayas dado cuenta de lo que se está gestando y que hasta veas esa situación como normal, porque para eso nos pagan, ¿no?, para hacer que algo funcione y le dé utilidad a alguien, añadiendo más funcionalidad e implementado los requisitos.

Pero del mismo modo, sin darte cuenta, estás plantando la semilla del caos en tu proyecto, sobre todo si éste tiene una vida de muchos años e infinidad de cambios que soportar, o incluso ni sospechas el tipo de cambios que se van a exigir a medio plazo, que suele ser lo habitual. 

¿Hay algún negocio acaso que sepa de dónde va a venir su crecimiento en unos años? Son muy pocos los que pueden tener una idea de ello. Esto es, si la aplicación que construyes va a soportar a dicho negocio, no tenemos ni idea de la forma en la que va a evolucionar.

Pasa el tiempo, la aplicación o sistema crece desorbitadamente y nos encontramos viviendo en un caos constante. El crecimiento orgánico descontrolado del sistema ha creado un monstruo inmanejable.

Este caos puede venir de diferentes formas: un sistema cada vez más frágil (tocas aquí y algo se estropea allí), funcionalidad añadida con demasiada celeridad sin respetar la forma de hacer las cosas en ese proyecto (esto es, sin seguir el diseño, si es que lo hay claramente), necesidad de pasar demasiado tiempo para cambiar cualquier detalle (el tiempo es dinero, coste para el proyecto que alguien tiene que pagar), y, como por arte de birlibirloque, llega un momento en que añadir / poner / quitar algo en el proyecto se convierte en una auténtica pesadilla, y echamos de menos entonces el momento aquel en que lo comenzamos con tanta ilusión, cuando el bebé aún no se había convertido en ese adolescente rebelde e insufrible...

Al cabo del tiempo, tienes que mantener un sistema frágil, muy acoplado y con un diseño más monolítico que flexible.

Esto es: el crecimiento orgánico de un proyecto de forma descontrolada conduce a un proyecto espagueti y costoso de mantener y evolucionar. ¿El resultado? Desarrolladores frustrados y responsables que en algún momento tienen que defender ante la dirección volver a hacerlo todo desde el principio, pero "mejor". En ocasiones, hasta se defiende una nueva "versión" cuando en realidad se trata de tirarlo todo a la basura y volver a construir el sistema desde el principio.

La cuestión que quiero plantear aquí es por qué se produce esta situación insostenible, situación que he vivido trabajando con algunos de mis clientes y reconozco que no es para nada agradable.

La dinámica es bien conocida: añadir más y más funcionalidad de forma casi descontrolada porque el tiempo apremia y el negocio necesita ya toda esa funcionalidad que exige, aumentando la bola de nieve hasta que llega un momento en que ésta nos aplasta.

La forma de evitarlo es también bien conocida.

Este es un principio universal en software: el coste de actuar al final (cuando ya es demasiado tarde) es mucho mayor que actuar repetidamente a lo largo de la vida del proyecto para evitar la situación anterior.

Pero, actuar... ¿en qué exactamente?

Es lo que yo llamo realizar "paradas técnicas", sobre todo, insisto, en proyectos o productos que deben tener una vida de años.

No hay más, esta es la receta: parte de nuestro tiempo de trabajo debe enfocarse en mejorar el diseño y arquitectura de la solución.

No hablo de hacer pequeñas mejoras en el día a día limpiando esto y aquello, refactorizando aquí y allá. Hablo de pasar un tiempo dedicado exclusivamente a analizar integralmente la solución para encontrar y sintetizar mejoras que permitan su crecimiento de modo mejor y más ordenado.

Estimo que a esta actividad hay que dedicar aproximadamente un cuarto del tiempo disponible al trabajar en un proyecto de largo recorrido.

Así es, puede parecer mucho tiempo, pero mi experiencia me demuestra que este paso atrás aparente, permite después avanzar mucho más rápido consiguiendo una solución mantenible y de mejor calidad (y con menos coste).

Lo he visto: si te dedicas a añadir funcionalidad continuamente, sin pararte a reflexionar si el diseño y la arquitectura se van ajustando a ese crecimiento funcional, tarde o temprano tendrás una patata caliente sobre la que alguien tendrá que responder.

Dedica uno de cada cuatro o cinco sprints o ciclos de trabajo a asentar la funcionar ya existente (parada técnica), mejorando cualquier aspecto que creas conveniente, refactorizando aún más el diseño, mejorando la arquitectura y los procedimientos de gestión de la configuración y despliegue. Puede parecer que ese esfuerzo es un gasto (ya que no añade nada nuevo al sistema), pero el tiempo te demostrará que ese esfuerzo reducirá drásticamente los problemas en el futuro y permitirá añadir más características más adelante con menos dificultad.

Igual que la regla de pareto 80/20 (que viene a decir algo así como que el 80% de los resultados vienen de un 20% del esfuerzo), en software afirmo que el 25% del tiempo de trabajo debe dedicarse a mejorar el sistema actual para permitir su crecimiento futuro, al menos en los proyectos que deben durar años de desarrollo con una gran cantidad de cambios.

Un paso atrás (en apariencia) pero que nos permitirá dar varios adelante con mayor certeza, seguridad y calidad.