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

Este error clásico, de libro, consiste en forzar el uso de un conjunto de tecnologías para una solución sin hacer el ejercicio intelectual previo de validar si esas tecnologías son las adecuadas o no para ese tipo de proyecto.

Las razones que hacen que caigamos en este error recurrente, en mi opinión, siempre son algunas de las siguientes:

  • Por pura pereza: puesto que conozco mejor las tecnologías x, y o z, no me voy a molestar en aprender o indagar otro tipo de cosas que quizá serían más convenientes para este proyecto.
  • Porque la política de la empresa es trabajar con tecnologías de x, sí o sí y no hay que darle más vueltas.
  • Porque en la estimación del esfuerzo, no hay cabida para incluir una curva de aprendizaje en nuevas tecnologías más apropiadas para ese nuevo trabajo.
  • O lo que es peor todavía: porque me gusta la tecnología x y quiero jugar con ella, ahora tengo la oportunidad, valga o no valga para el proyecto en el que me han metido, así por fin puedo jugar con ella a costa de mi trabajo en la empresa, aunque el resultado sea penoso.

En cualquier caso, las consecuencias de no hacer ese ejercicio previo antes de lanzar a un equipo de desarrollo a construir una nueva solución, son malas y a veces catastróficas.

Sin ir más lejos, en el último año he visto cómo se ha tirado a la basura la solución inicial, pero ya en explotación en una gran compañía eléctrica, para rehacerla completamente con tecnologías más apropiadas para el escenario que se planteaba. De este modo vemos que el no considerar ese aspecto del software al comenzar un nuevo proyecto tiene un coste económico que alguien tendrá que pagar, tu propia empresa o tus propios clientes (encareciendo tus servicios y perdiendo así oportunidades competitivas).

Esto ocurre en pequeñas empresas, pero también en esas que llamamos grandes, con recursos suficientes para hacer todas las auditorías del riesgo del mundo...

Hay que preguntarse siempre y justificar al máximo posible si es conveniente o no usar ASP.NET MVC o cualquier otro framework para interfaces de usuario web en el contexto de un proyecto particular, si es mejor AngularJS o Backbone, si es necesario o no una base de datos relacional (MySql, SQL Server, etc.) o repositorios de información no estructurada (MongoDB, Cassandra, Amazon Simple DB, SQL Tables de Azure, etc.). 

No toda tecnología es adecuada para cualquier tipo de proyecto. Esto parece una obviedad, pero el modo en que veo que en ocasiones se elige qué emplear en cada proyecto me da muchísimo que pensar, cuando no esa motivación nace de la última moda...

En mi opinión, esta debe ser una decisión del líder técnico del proyecto, si es que lo hay, ya que sólo se puede aproximar a una solución adecuada si cuentas con suficiente experiencia y si conoces en alguna medida todas las posibilidades tecnológicas existentes que podrían dar solución a un proyecto en particular.

No sé si es acertado o no, pero por esta razón me gusta promover dentro de la delegación de trabajo que dirijo sesiones internas y completamente desinteresadas en las que cada miembro del equipo expone algo que le interesa, tenga que ver o no con los proyectos que gestionamos en el día a día. Esas sesiones internas nos las preparamos en su mayor parte fuera del horario laboral, pero el resultado es que ampliamos así el acervo tecnológico existente y cuando nos llega algo que afrontar totalmente nuevo, tenemos, cómo decirlo, un horizonte más claro por haber tenido más contacto con un conjunto de tecnologias más amplio. Evidentemente esto requiere de un esfuerzo difícil de valorar, pero que aporta un valor intangible extraordinario en lo que hacemos, o eso creo.

En cualquier caso, el cliente nunca te va a pagar la curva de aprendizaje que necesitaría al comenzar con una nueva tecnología que desconoces, aspecto que distingue radicalmente nuestra profesión de otras: si intentamos repercutir en el cliente ese coste, seremos más caros y por tanto, más débiles de cara a la competencia.

Todo esto que en cierto modo no deja de ser sutil (porque sus consecuencias son difícilmente medibles); es algo con lo que tenemos que enfrentarnos queramos o no. A lo mejor si trabajas en una gran empresa donde alguien te dice con pelos y señales lo que tienes que hacer y cómo, los tiempos, etc., esta discusión sea irrelevante, pero la mayoría de desarrolladores se tienen que enfrentar a estas decisiones continuamente.

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.

Lo habitual es que se trabaje dejando muchísima deuda técnica, y esto es así porque es muy difícil evaluar el impacto en tiempo y falta de productividad que produce meses o años después cuando el gestor de un proyecto (tu jefe, vaya), lo que quiere son resultados inmediatos (o sea, pan para hoy y hambre para mañana).

Como el jefe soy yo mismo (aunque suene mal decirlo), una de las máximas que sigo en los proyectos que desarrollamos es que las cosas se tienen que terminar limpias y claras; si de lo que se trata es de reducir riesgos (cosa que se entiende mejor en otros contextos de la compañía) entonces esto es así como una garantía para el futuro: reducimos riesgos refactorizando diseños, limpiando código y simplificando. Curiosamente, el intentar trabajar así no nos ha hecho fallar en ninguna fecha de entrega acordada, lo cual es buena señal.

Puesto que en esencia un proyecto se paga por tiempo dedicado a él, no siempre podemos pararnos todo lo que nos gustaría a hacerlo lo mejor posible. No obstante, mi opinión es que si te paras a tratar de reducir o eliminar esa deuda técnica, todo el tiempo que en ese momento pierdas lo recuperarás multiplicado más adelante.

También es habitual encontrarte con gente que resuelve rápido, pero la pregunta no es cómo de rápido trabajas en software, sino cómo de limpio y mantenible haces el trabajo que entregas. Todo esto suele ser muy sutil, subjetivo, difícil de evaluar, me temo.

En esta ocasión, a las dos horas de revisar lo que se hizo en su día, ya estaba en condiciones de estimar el tiempo que podríamos tardar en añadir la nueva funcionalidad requerida por uno de nuestros clientes.

No hay una varita mágica para llegar a crear un software que te permita asumirlo de nuevo con comodidad al cabo de algunos meses o años incluso, depende del tipo de proyecto y claro está, tu propia experiencia acumulada. Sin embargo, cuando se siguen unos simples principios durante toda la solución es mucho más fácil (y rentable) volver a trabajar en ella como en el primer día.

En este caso que comento, la varita mágica era básicamente lo siguiente:

  • Ese módulo a evolucionar seguía la arquitectura de diseño general de la solución. Nada de excepciones en el diseño alejado del general, las cosas estaban ahí donde un esperaba encontrarlas.
  • Las clases son suficientemente pequeñas como para percibir claramente qué hace cada una, qué propósito único resuelve y cómo encaja con el resto.
  • Las pruebas te permiten ver cómo se usa cada clase; los tests no sólo te sirven para saber si lo que has escrito funciona, también te permiten documentar el uso del código que generas.
  • La inyección de dependencias te permite localizar rápidamente dónde están definidas y cómo se ensamblan las partes inyectables de la solución. Si está bien planteada, una gran parte funcional del sistema será inyectable.
  • Ausencia total de código obsoleto o muerto (que nunca se ejecuta pero que a alguien le ha dado pena eliminar). Es decir, no hay basura que te distraiga de captar lo esencial.
  • Estructura de la aplicación extraordinariamente ordenada y entendible.
  • Nombre de métodos y clases claros y bien elegidos.

En ocasiones nos surge la pregunta de qué hacer cuando se está en una fase de definición o se tienen huecos de tiempo por llenar y que podrías usar productivamente. La respuesta está clara: siempre puede buscar aplicar todos los puntos anteriores a la solución en la que trabajas.

Para casi cualquier sección del código final, su calidad no surgió a la primera cuando se desarrolló hace algunos años, sino que es el producto de muchos refactorings y muchas fases de trabajo, algunas de las cuales tenían únicamente el propósito de mejorar la estructura interna y el diseño del sistema.

Quizá el mejor desarrollador no es aquel que rápidamente encuentra y resuelve cómo hacer algo; también es un magnífico desarrollador el que se para un momento para mejorar lo que ya funciona en algún aspecto, el que presta mucha atención a los detalles que nos permiten años después poder retomar fácil y cómodamente lo que hacemos ahora. Es algo así como dar un paso atrás para dar después un gran salto adelante.

Es ya muy antigua la polémica por la que un desarrollo software se debe considerar horroroso, decente, regular o magnífico, hay tantos puntos de vista como esas críticas contradictorias de cualquier película o la descripción de una misma noticia por varios periódicos con distintas líneas editoriales; es un factor también tremendamente subjetivo.

No obstante, de lo que sí podemos estar seguros es de que una solución que acumula mucha deuda técnica es bastante peor que aquella en la que no existe. La pregunta no es sólo ¿funciona o no funciona?, también ¿será fácil retomar esta aplicación en el futuro por alguien que ha participado en ella?

Como ocurre en muchos temas y como decía Benedetti: "Cuando creíamos que teníamos todas las respuestas, de pronto, cambiaron todas las preguntas". Según las preguntas que te hagas acerca del tipo de calidad que esperas en el software que desarrollas (¿es rápido, eficiente, usable, mantenible, de diseño limpio, traza bien los errores, etc.?) así será este.

¿Desarrollas pensando en el corto plazo o un poco más allá?

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.

Por su extensión, he dividido este trabajo en las siguientes secciones.

De la idea al proyecto

En cierta medida, emprender es probar si lo que tienes en mente puede funcionar o no y encontrar un mercado para esa idea o producto. Si de lo que se trata es de probar algo y según los resultados obtenidos, evolucionarlo tantas veces como sea necesario, entonces todo esto huele un poco a ágil y a lean, a iterar sobre algo hasta conseguir un buen resultado.

Muchas veces los errores son grandes maestros. Allá por el 2008 tuve mi primer contacto con un proyecto y una idea emprendedora que fue un auténtico desastre a los pocos meses; la razón es que confundimos la idea con su realización, la amistad con un relación de compromiso en un proyecto común y, por supuesto, una ignorancia total sobre cómo darle cuerpo empresarial a lo que queríamos desarrollar, entre otros muchos errores... Ese primer proyecto fracasado lo recuerdo con cariño por todo lo que me enseñó; también es cierto que ahora se hace mucha apología del fracaso como herramienta de aprendizaje. Digo yo que en un punto intermedio entre la indolencia y el no fustigarnos al tropezar estará la virtud.

En cualquier caso, desde entonces han pasado muy cerca mía multitud de proyectos de conocidos, charlas en eventos sobre modelos de innovación y muchas, muchísimas lecturas al respecto. Igualmente proyectos personales con mayor o menor éxito.

Si estás pensando en poner en marcha una idea que implica el desarrollo de cualquier tipo de software me gustaría decirte que el desarrollo del mismo es tan sólo el centro de un universo de variables y tareas que hay que hacer bien, relacionadas o no con el software pero que sin ese universo tu idea no llegará a ninguna parte, me temo.

Como desarrolladores nos gusta dedicar gran parte de nuestro tiempo programando, creando artefactos que hacen algo, pero si desarrollamos un proyecto emprendedor basado en software, entonces no podemos ignorar dotarle de la estructura emprendedora correcta. Y, por supuesto, estar dispuesto a gastarte algunos eurillos... Esa coletilla de comenzaron sin nada es sólo un mito urbano que pudo funcionar para algún visionario pero de ninguna manera es lo general. No entiendo cómo alguien que dice creer en su idea después no es capaz de invertir en ella algo de dinero.

Veamos cuáles son esas piezas fundamentales en las que casi ningún emprendedor de software ilusionado apenas repara y ni le da importancia y, sobre todo, cómo algunas decisiones desde el punto de vista del software son fundamentales.

La idea, por evidente que parezca decirlo, sólo existe en la cabeza

¡Qué sorpresa! En otras palabras, lo que quiero decir es que si esa idea no sale de la cabeza cobrando vida mediante la acción, ahí quedará, como un ente mental sin valor. Para la mayoría de la gente, las ideas se quedan ahí dentro, sólo para unos pocos la idea es lo suficientemente fuerte para pasar a la acción.

En multitud de ocasiones pensamos idílicamente en un proyecto maravilloso, único, que podría funcionar, es decir, generar usuarios y clientes y por tanto, ingresos. Entonces hacemos planes de cómo hacer esto o aquello, sobre qué tecnologías usar (a menudo son siempre las que más conocemos), las posibilidades que se podrían abrir y un largo etcétera. 

En ocasiones, también, estas maravillosas ideas no son más que quimeras mentales para huir de una realidad personal o laboral que no te gusta. Esto lo he visto hasta la saciedad.

Si eres un iluso, quédate en el mundo de las ideas, pero sólo las que inducen a la acción, al trabajo y al esfuerzo, saldrán adelante.

No hace falta inventar un proyecto maravilloso y totalmente innovador: muchas veces, propuestas que parecen triviales y hasta aburridas son las que encuentran un mercado y una viabilidad.

En mi opinión existen dos momentos claves para pasar de esta fase (llamémosla de la idea al proyecto). La primera es sentarse tranquilamente a poner por escrito una descripción clara del proyecto, su misión, sus expectativas, etc. Poner por escrito todo lo que tenemos en la cabeza tiene un valor incalculable por la sencilla razón de que te obliga a definir cosas que hasta ese momento sólo eran entelequias un poco vagas. Muchas ideas no pasan de esta prueba...

Existen técnicas para pasar al papel una idea de proyecto, como la técnica del canvas (o lienzo), con herramientas online que te ayudan a su definición, como Canvanizer. Del mismo modo, los mapas mentales también ayudan en esta fase.

El segundo momento, si es que se ha superado el primero, es adquirir un compromiso con uno mismo. Ningún proyecto incipiente se va a desarrollar si antes no nos comprometemos personalmente con él, esto es, no nos comprometemos a sacar tiempo extra (quitándonos tiempo de ocio, de fines de semana, etc.). Sólo cuando hay compromiso personal es cuando se llega a algo. Lo sorprendente es que cuando crees en algo, no hay esfuerzo que valga, ya que estás deseando dedicarle tiempo.

Al menos eso funciona para mí: cuando hemos terminado una fase de un proyecto a tiempo, o realizado cualquier proyecto personal sea del tipo que sea, la mayor satisfacción me la produce el haber cumplido con un compromiso personal previo autoimpuesto.

El Arte de EmpezarSi este paso a la acción te cuesta trabajo necesitas urgentemente El Arte de Empezar de Guy Kawasaki.

Hay que validar la idea

Me gusta el enfoque lean en la realización de proyectos, sobre todo si son proyectos basados en software que viven en un mundo acelerado en donde los paradigmas cambian tan rápido. Lo que triunfa ahora es la disrupción. 

Vivir con menos (Albert Cañigueral)Hace poco he terminado de leer este maravilloso libro de Albert Cañigueral y de título Vivir Mejor con Menos, descubre las ventajas de la nueva economía colaborativa y, como me ocurre a menudo, no puedo evitar poner gran parte de las cosas que leo en relación a mi actividad como desarrollor de software y gestor de proyectos. 

Por decirlo en pocas palabras, me siento entusiasmado por toda la información que ofrece Albert en su libro y por las enormes oportunidades que se están abriendo ya en este nuevo paradigma económico que sutilmente se está abriendo paso poco a poco. 

La economía compartida (o sharing economy), por definirla brevemente, consiste en mantener una relación distinta con los objetos que consumimos y usamos: pasamos de relacionarnos con ellos en forma de propiedad a considerarlos como un servicio de intercambio, de ahí lo de consumo colaborativo.

Los paralelismos entre este concepto y Saas, Paas y Iaas (software / plataforma / infraestructura como servicio) son evidentes. De hecho, uno de los productos que comercializamos en la compañía para la que trabajo se ofrece como servicio con suscripciones periódicas y lo más sorprendente es que todos los clientes usan esta modalidad. No compran el producto, sino que pagan periódicamente por su uso.

Cuando se habla de economía compartida a uno se le viene a la cabeza Bla Bla Car o Airbnb (plataformas muy populares en mi país); no obstante, eso es sólo la punta del iceberg; lo más interesante de todo es que es una renovación de viejas formas de organización, quizá ancestrales, pero que con Internet como palanca su efecto es infinitamente mayor. Cuando hablamos de Internet, lo hacemos de software...

Gracias a infinidad de iniciativas que se están poniendo en marcha y todas a través de portales y aplicaciones móviles, se están desplegando todas las posibilidades de organizar una economía menos centrada en el hiperconsumo y más en la colaboración y la confianza entre los individuos. 

Quien piense que carreteras llenas de vehículos con un único conductor, por poner un ejemplo llamativo, es un futuro sostenible para nosotros y nuestros hijos, va por mal camino. Cambiar de un paradigma económico a otro ni sucede en dos días y además ocurre casi de manera imperceptible con tiempos en los que se solapan ambos para llegar a darnos cuenta de que en una o dos décadas hacemos las cosas de otra manera.

Para ello la economía no cambia porque sí, sino que lo hace porque antes ha cambiado la mentalidad de las personas.

Todo esto, como digo, lo están posibilitando infinidad de sitios en Internet como forma de comunicación básica, ¿cómo si no? Vemos cómo el trabajo de muchos desarrolladores, por tanto, no es sólo escribir software, también existe una responsabilidad ya que a través de esos desarrollos cambiamos la forma en que la gente se relaciona y también cómo puede evolucionar la economía. Aunque parezca grandilocuente, es así.

En ocasiones digo eso de que es un magnífico momento, quizá el mejor, para ser desarrollador profesional porque parte de la economía se está moviendo hacia lo digital. Sin embargo Albert en su libro indica que no queda ahí, sino que también la misma tecnología está modificando cómo nos movemos, relacionamos, consumimos y, en definitiva, está modificando la economía tradicional, el cambio es por tanto, recíproco. Apasionante. 

Tal y como afirma Albert, todo ello se está produciendo por la existencia de Internet, su uso masivo, la cultura digital, la omnipresencia de la tecnología y también por la crisis económica (que fomenta en las personas la necesidad de buscar alternativas que no dependan directamente de consumir con dinero).

La economía compartida es mucho más que poder compartir los gastos de coche en tus desplazamientos habituales, además:

  • Couchsurfing: conseguir alojamiento basado en la confianza entre individuos y tu reputación en la red. 
  • Carcharing y carpooling: no sólo compartes trayectos (como conductor o pasajero), también puedes ofrecer tu propio coche para que lo usen otros mientras a ti no te hace falta.
  • Alojamiento y alquiler de espacios entre particulares: ofrecer alojamiento a terceros en tu propia casa y tú mismo conseguir alojamiento gratis o de pago, siempre entre particulres y basado en la confianza. Esto incluye también el intercambio de tu propia casa con la de otro particular.
  • Coworking: ¿por qué no compartir los espacios de las oficinas entre distintas empresas o freelancers, reduciendo costes y además posibilitando el networking entre ellos?
  • Finanzas participativas como el crowdfunding (apoyo a proyectos) y el crowdlending (préstamos entre particulares), especialmente importante en aquellos países donde la crisis económica ha supuesto una enorme restricción en el acceso al crédito... Esto también incluye inciativas de ahorro colectivo.
  • Intercambio de divisas entre particulares, quitándote de enmedio al agente bancario con sus comisiones.
  • Monedas sociales virtuales, siendo el bitcoin como la más conocida aunque hay otras.
  • Bancos de tiempo: no hace falta comprar el servicio de alguien, puedes intercambiar lo que todas las personas tienen, que es ¡el tiempo!. Así le ayudas a tu vecino un día en algo y él a ti en otra ocasión, por poner un ejemplo.
  • Mercados de segunda mano: a mí por lo menos, me remuerde la conciencia cuando tengo que tirar algo que aún podría usar alguien pero que yo no necesito. Al revés también, ¿por qué no adquirir algo que necesitas y que necesariamente no tiene por qué ser nuevo? Reducimos así la fabricación continua de productos y los reutilizamos más antes de tirarlos a la basura.
  • Grupos de consumidores, compras colectivas, venta directa entre productor y consumidor y un larguísimo etcétera.

¿Ejemplos? Hay cientos y muchos con carácter local, por poner algunos en los que me he interesado especialmente: Comunitae y Lendico (para préstamos colaborativos), Home for Exchange (para el intercambio de casas entre particulares), BlaBlaCar y Carpooling (para compartir coche), Social Car (para alquier de coches entre particulares), Goteo, Verkami, Kickstarter e Indiegogo (para la búsqueda de financiación en proyectos), Puddle y TuTanda (como plataformas para el ahorro colectivo), Transferwise (para el intercambio de divisas entre particulares) y muchos más.

¿Alguien puede pensar que todas esas plataformas son sólo una prueba de concepto? Ni mucho menos, son realmente la cara visible de un nuevo paradigma con el que consumimos y compartimos de otra forma.

Yo creo que este movimiento, si es que se puede llamar así, no tiene marcha atrás y que es ahora cuando se están dando los primeros pasos. Con sus luces y sus sombras, lo que sí está claro es que una economía basada en el crecimiento ilimitado del PIB en un mundo cuyos recursos son finitos y donde el individualismo exacerbado vacía las farmacias de ansiolíticos y antidepresivos, este emergente paradigma económico no basado en el dinero exclusivamente y en la acumulación de bienes, sino en el intercambio y en el uso de esos bienes, nos acerca un poco más a esa idea de dejar el mundo algo mejor que como nos lo encontramos. No es idealista, es una realidad que poco a poco está cambiando cómo nos relacionamos y ahora cómo consumimos. Sí, estoy firmemente convencido de que el software (y nuestro trabajo) se puede poner al servicio de causas de ese tipo dándole mayor sentido a nuestro día a día.

¿Y a mí qué, si yo como desarrollador hago lo que me encargan?, podría pensar cualquiera. Sin embargo, este tipo de portales e inciativas que aspiran a cambiar la forma en nos relacionamos e intercambiamos bienes y servicios, implican conocer ciertas tecnologías para su desarrollo e igualmente introduce un componente social en los productos, por poner un ejemplo:

Trabajar en distintos ámbitos tiene algo de fascinante, terminas dándote cuenta de cómo lo que haces en uno enriquece los demás y al revés.

Ahora mismo estoy trabajando en un proyecto basado en MEAN que al mismo tiempo me está permitiendo sentar las bases de un proyecto de I+D que estamos realizando en la compañía para la que trabajo y que desarrollaremos durante 2015 y 2016; este proyecto consiste en un sistema de detección y diagnóstico de incidencias para el despliegue de cuatro millones de smart meters, de la mano de una compañía de distribución eléctrica nacional. Big-data con Hadoop, su despliegue en la nube con Azure, el análisis y explotación de esos datos más una capa de servicios que consumirán terceros sistemas serán las partes esenciales del proyecto y en cuyas tecnologías nos vamos a meter de lleno en los próximos meses.

¿Qué puede garantizar que tendremos éxito en ese nuevo proyecto reconociendo que algunas de las tecnologías que vamos a usar son relativamente nuevas para nosotros?

Si crees conocer muy bien la tecnología X, ¿qué te hace pensar que serás capaz de sacar provecho a otra totalmente distinta?, ¿te asegura acaso que vas a tener éxito con un nuevo stack que debes usar para un nuevo proyecto cuya naturaleza no tiene nada que ver con lo que has hecho hasta ahora?

Para un responsable de proyectos, ese es un riesgo que hay que considerar a fondo.

Un desarrollador de software o un equipo de trabajo sólo pueden tener éxito en cualquier proyecto si son capaces de mantener firmemente una serie de principios de desarrollo y métodos que se pueden aplicar a cualquier tipo de tecnología.

Por tanto, aún teniendo valor, me da siempre qué pensar cuando escucho afirmaciones del tipo "soy experto en C#", "nivel avanzado de administración de Sql Server", o "desarrollador front-end con AngularJS", etc, cosa que se suele ver en todos los currículums que me llegan (y por qué no, en el mío propio hasta hace pocos años). Todo eso es fantástico, pero no suficiente...

Si dominas una serie de principios serás bueno y tendrás éxito en cualquier proyecto software independientemente de las tecnologías que se usen.

Para mí, el currículum ideal de un desarrollador profesional de software estaría compuesto de afirmaciones de este tipo:

  • Participación activa en los siguientes proyectos:....
  • Experto en patrones de diseños y antipatrones.
  • Experiencia en enfoques ágiles para proyectos software.
  • Conocimiento sobre principios de diseño como inyección de dependencias, inversión de control, DRY, KISS, SoC y un largo etcétera.
  • Desarrollo con integración continua y cobertura total con pruebas unitarias y de integración.
  • Experiencia de análisis de calidad de código.
  • Habituado a refactorizar código y desarrollo de código limpio.
  • Experto en realizar código mantenimible y evolucionable.
  • Dominio de arquitecturas software escalables.
  • Conocimiento de principios de usabilidad en interfaces de usuario.
  • etc.

Aunque sólo son un ejemplo, todas esas aptitudes son mucho más importantes que dominar cualquier tecnología en particular: con cualquier lenguaje, sistema operativo, framework o entorno de desarrollo se pueden aplicar esas técnicas, principios y métodos impresindibles para generar productos software de calidad.

Cualquier desarrollador con dominio de todos esos temas va a seguir aplicándolos con cualquier nueva tecnología con la que tenga que comenzar a trabajar.

Aparte de una actitud positiva hacia el trabajo y buena disposición a trabajar en equipo, a lo anterior añadiría afirmaciones de tipo "Mis últimas lecturas técnicas han sido...", "Asistencia en el último año a eventos como...", "Participación en el blog X", etc. Aunque ya todo esto sería mucho pedir.

Es difícil, lo sé, cuando muchas compañías piden "expertos programadores en java", por poner un ejemplo, sin darse cuenta de que cualquier desarrollador mínimamente experimentado puede acercarse al mundo java con un par de semanas de estudio y dos o tres buenos manuales, aunque no por eso va a hacer un buen trabajo necesariamente. Sí va a hacer un buen trabajo si está habituado a implantar todos los conceptos anteriores con cualquier otra tecnología. Otra cosa es que los gestores de proyecto tengan claros ese tipo de consideraciones...

En cierto sentido, todo lo anterior es como la gramática y la ortografía necesarias para escribir una buena novela, en donde el saber escribir una palabra tras otra vendría a ser a conocer bien la tecnología X.

¿Sabes sencillamente escribir aunque tengas un buen vocabulario sin tener claras la gramática que nos permite generar un trabajo de calidad?

Este es el comienzo de un nuevo proyecto. 

Soy de la opinión de que si no eres capaz de explicar a otros aquello que crees que sabes y que usas en el día a día, seguramente no sepas tanto como crees. Enseñar, sea de la forma que sea, mediante posts en un blog, en artículos o en videologs, siempre te permite ahondar aún más en los temas que tratas. Tengo la impresión de que en la cultura anglosajona se fomenta más el mentoring, no es por casualidad, tanto dentro como fuera de la compañía o las empresas en las que trabajas.

Durante 2014 me he metido de lleno en ciertas tecnologías y tendencias relacionadas con conceptos como big-data, responsive design, plataformas para la economía colaborativa, el Internet de las Cosas, etc., al tiempo que me he esforzado aún más en mejorar técnicas de gestión de proyectos software (y que en gran parte consisten en tener una gran empatía con el equipo que dirijes). Como digo siempre, si no mejoras en las competencias con las que trabajas, entonces es que empeoras...

Me gusta NodeJS, lo he empleado este año pasado en un proyecto profesional para un cliente y ahora mismo lo estoy exprimiendo de lleno en uno de mis proyectos para este año. Al mismo tiempo, no encuentro en los pocos libros acerca de NodeJS escritos en castellano todo lo que me gustaría encontrar en ellos; es más, creo que existe una gran laguna que hay que cubrir.

¿Será NodeJS objeto de olvido dentro de unos años?

Aunque en software nunca se pueden hacer predicciones a medio y largo plazo porque no siempre sobreviven las mejores tecnologías, creo que NodeJS y sus derivados va a pervivir con nuestra forma de enfocar proyectos escalables mucho tiempo.

La razón, básicamente, es que es relativamente sencillo de aprender, porque se usa Javascript que es el lenguaje que cada vez está más omnipresente y porque está creciendo alrededor del core un ecosistema de módulos que lo enriquecen enormemente. Por tanto es el momento de preparar en condiciones, con rigor y calidad un buen libro sobre NodeJS.

Pero, ¿otro libro de NodeJS?, ¿será uno más o aportará algún enfoque nuevo?

Existe un gran vacío de literatura técnica en castellano sobre esta tecnología; lo que se encontrar, aún estando muy bien, no deja de ser en mi humilde opinión sencillas introducciones a lo básico de NodeJS sin dar un enfoque global a la realización de un proyecto profesional y listo para salir a un entorno de producción. O sea, que necesitarías varias publicaciones así como muchos artículos y búsquedas en foros para atar todos los cabos y terminar una aplicación mínimamente profesional con NodeJS.

Describir los rudimentos de una tecnología no te prepara para usarla a fondo en un proyecto profesional. Los libros (tanto en castellano como en inglés) que he leído, aún gustándome, carecen de lo siguiente:

  • Se presentan siempre ejemplos sencillos y de juguete. Lo cual pedagógicamente está bien pero está lejos de resolver problemas reales, de los que se presentan en cualquier proyecto con NodeJS.
  • No se indica cómo implementar técnicas básicas de clean code y refactoring con NodeJS.
  • Tampoco se hace hicapié sobre la mejor forma de estructurar un proyecto según la naturaleza de éste.
  • No hay un catálogo de buenas prácticas para que un proyecto en el que se emplea total o parcialmente NodeJS se desarrolle con lo que la comunidad acepta como lo más correcto.
  • Existe un gran vacío en relación a implementar tácticas de seguridad en un proyecto web realizado con NodeJS.
  • Tampoco se encuentran fácilmente las mejores prácticas para desplegar un proyecto con NodeJS en producción de cara a su mantenimiento.
  • No se profundiza en ninguno de todos esos módulos que han ido creciendo alrededor de NodeJS y con los que se ha creado un ecosistema realmente rico y maduro para la realización de aplicaciones profesionales (Q y promises, passport, sequelize, async, underscore, lodash, etc.)
  • Del mismo modo, no se sugiere cómo usar correctamente un framework de pruebas unitarias con NodeJS y cómo integrarlo bien en cualquier proyecto. 
  • Igualmente, tampoco se aclara correctamente cómo hacer una separación de responsabilidades (separation of concerns) en un proyecto con la especial idiosincrasia de NodeJS para su fácil testeabilidad y buen mantenimiento.
  • En relación a proyectos web, existen bastantes cosas acerca de Express, pero en pocas se incluyen los elementos necesarios para producir una aplicación web con ficheros css y js, minimizados, concatenados, etc.
  • Tampoco se aborda cómo integrar el consumo de recursos externos publicados en forma de servicios REST o cómo construir tu propia capa RESTful.

No es que quiera abarcar todos esos temas con una profundidad tremenda, pero sí con el suficiente detalle como para mostrar una visión global completa.

Así las cosas, hasta ahora si decides meterte de lleno en esta fantástica y prometedora tecnología, que sepas que tendrás que hacerte de alguno de los libros disponibles actualmente y que además tendrás que bucear en multitud de contenidos extra para ver de manera global y holística todo este Universo NodeJS.

De ahí el nombre de Universo NodeJS: no es sólo esa tecnología, su Core API y el uso más o menos avanzado de Javascript (ECMAScript versión 5), sino además multitud de módulos, técnicas y buenas prácticas para el éxito de un proyecto.

¿Cómo se publicará el trabajo?

Los capítulos, ya planteados y organizados, se irán produciendo a lo largo de los próximos meses con una dinámica similar a como fui liberando las secciones de El Libro Negro del Programador: adelantos cada varias semanas de los capítulos con el contenido fundamental hasta completar la publicación del libro con todo el material.

¡Arrrgh! Llevo elucubrando acerca de este proyecto desde hace muchos meses de modo que ahora doy el pistoletazo de salida para contribuir, modestamente, a formar más y mejor a nuestra comunidad de desarrolladores profesionales de software con esta magnífica tecnología.

Recuerda: no somos una simple acumulación de conocimientos sbre esta o aquella tecnología, sino aquello de utilidad que somos capaces de hacer para otros con ellas.

Este comienza a convertirse en uno de mis mantras favoritos: "refactorizar o morir".

Recientemente he vuelto a poner en práctica una de las mejores virtudes de realizar este tipo de trabajo continuamente. El resultado finalmente es muy satisfactorio después de muchos momentos tipo "esto está quedando fatal", "así sólo voy a llegar a una solución muy enmarañada", etc. El desánimo cunde rápido, sobre todo si se trata de un pequeño proyecto que haces a ratos por las noches o fines de semana.

No obstante, una mínima tenacidad (y seguramente tirarlo todo a la basura y volver a empezar en algún momento), te hace llegar a una buena solución que no sólo funciona, sino que además es ampliable y evolucionable con cierta facilidad.

Se habla mucho de productividad; para mí es muy sencillo describir qué es productivo y qué no en software: las soluciones fáciles son más productivas que las inextricables que sólo pueden entender sus autores, aquello que nos permite ganar velocidad de desarrollo es más productivo y con ello conseguiremos más con menos esfuerzo. Nada más. Así de contundente y simple.

Hay quienes se procupan de mejorar el código de una aplicación en alguno de sus aspectos en algún momento del trabajo: al final, cuando ya todo funciona, de vez en cuando... Sin embargo, las ventajas de incorporar estas tareas de mejora en todo momento no siempre se aprecian como productivas, mucho menos cuando nos acercamos peligrosamente a las fechas de entrega y comenzamos a dejar cabos sueltos (de los que nos acordaremos sin duda semanas o meses más tarde).

¿Por qué refactorizar cuando lo importante de una aplicación es que le funcione al cliente? Buena pregunta, y al mismo tiempo, ingenua. Quienes aún no ven claro las virtudes de invertir tiempo en este trabajo, deben saber que lo primero que se gana es velocidad de desarrollo, por tanto, productividad.

La velocidad con la que desarrollamos cualquier pieza de software viene a ser una medida de la productividad, sobre todo cuando ésta nos acerca al objetivo de entregar las funcionalidades que nos piden.

Tenemos que perseguir que el diseño o la estructura de la solución que vamos construyendo, con el tiempo nos permita avanzar más rápido y no lo contrario.

En esa aplicación en la que llevo trabajando un tiempo he ido aplicando continuamente todas las técnicas de mejora posibles: simplificaciones, abstracciones en clases de utilidad, mejora en la estructura de la solución, modularizaciones, etc, de modo que cada dos semanas he podido ver cómo el código de un commit de hace quince días no tenía nada que ver con el del último. Esto cobra especial relevancia cuando desde el principio no tenemos claro cómo vamos a implementar ciertos aspectos de la aplicación un poco complicados.

A medida que avanzamos en la solución y gracias a que aplicamos todo ese trabajo de mejora, vemos cómo poco a poco va surgiendo (emergiendo) un diseño cada vez mejor. "Mejor" es una palabra muy subjetiva y difícil de consensuar entre dos o más personas. Para mí, en software, algo es mejor si te permite desarrollar más rápido (invertir menos tiempo en la misma solución) sin perder calidad en todos los aspectos de esta.

Ese diseño elegante, sencillo, correcto, es el que nos permite a partir de un punto ganar velocidad. Llega un momento en que esto es así y es entonces cuando te das cuenta de que todo ese trabajo de mejora ha sido en realidad una buena inversión de tiempo que ahora se va a amortizar. Es como si tuviéramos una madeja de hijo que al principio cuesta mucho desenredar hasta que llega el momento en que es fácil y rápido sacar más y más hilo de ella.

En ese proyecto en concreto que estoy realizando, ha llegado un momento que he conseguido resolver todas esas partes más difíciles de manera tan sencilla y elegante que ahora lo que me queda es decorar el resto hasta finalizar la aplicación. Esto no habría sido posible si no me hubiera parado al principio con esa idea de mejorar la aplicación en todos sus aspectos.

Los comienzos de una aplicación en la que hay muchas dudas que resolver son duros, cuesta apreciar verdaderamente avances y tenemos la tentación de tirar por lo rápido y fácil, sin darnos cuenta que ese camino se volverá en nuestra contra con el tiempo.

Llega un momento en que esa mejor arquitectura y diseño para nuestro propósito es tan maduro que ya sólo nos queda seguir esa coherencia para terminar la aplicación con éxito.

Lo mejor, además, es que llegaremos al final con una solución limpia y fácil de mantener y evolucionar.

Algunas de las técnicas que he empleado hasta el momento son las siguientes:

  • A medida que el código crecía, he ido adaptando la estructura y distribución de este mucho mejor.
  • Clases largas las he ido abstrayendo en clases más concretas y sencillas con una relación lógica entre ellas (principio SRP).
  • Duplicidades las he aislado correctamente en sus servicios correspondientes (el frontend está basado en AngularJS).
  • He ido buscando continuamente todo aquello inyectable, es decir, todas aquellas dependencias que se podían sacar para implementar Inyección de Dependencias.
  • He simplificado muchos bloques de código similares con sus correspondientes funciones de utilidad.
  • Métodos de más de tres o cuatro parámetros los he ido simplificando.
  • y un largo etcétera.

Al final, todo este tipo de trabajo constituye un entrenamiento por el que terminas haciéndolo de la manera más natural y ni te planteas conscientemente el realizar esas actividades como algo separado del trabajo de desarrollo, sino como algo consustancial al mismo.

Sin clientes, ¿a quién le venderíamos nuestros productos o proyectos software?

Esto es evidentemente una obviedad, es una desfachatez siquiera comentarlo; sin embargo, no siempre tenemos a esos mismos clientes en cuenta para escucharles y que en cierta medida nos ayuden a mejorar todo aquello que hacemos y cómo lo hacemos.

Por lo general, no programamos o trabajamos en un proyecto cuyo cliente o usuario vamos a ser nosotros mismos, sino que siempre, de algún modo, vamos a realizar algo para que lo utilicen otros. No entiendo, por tanto, por qué no se trabaja intensamente con una actitud de escucha y recopilación activa de sugerencias y críticas para mejorar aquello que hacemos.

Es cierto esa frase ya clásica en software que dice que "el cliente no sabe lo que quiere" hasta que se le comienza a enseñar algo de esa nube abstracta de funcionalidad y requerimientos que pide. Pocos, muy pocos proyectos, comienzan con una definición clara y exhaustiva de requisitos. Por tanto, lo más normal (y natural) es que el cliente o nuestros usuarios comiencen a matizar y a solicitar nueva funcionalidad cuando ya por fin tiene algo entre manos que tocar y usar.

Esto no es malo, no hemos hecho nada erróneamente: sencillamente es lo habitual. Hay que vivir con ello y sabiéndolo, anticiparemos posibles problemas por desviaciones en tiempos y esfuerzos.

En realidad, esa falta de definición inicial es una gran ventaja si la sabemos usar correctamente.

Independientemente de quien esté más en contacto con tu usuario final, es imporantísimo para mejorar todo aquello que haces escuchar activamente las sugerencias, opiniones y críticas (positivas o no) de quienes en definitiva están usando el resultado de tu trabajo.

¿Y para qué? Sólo de esa manera vas a obtener una información muy valiosa:

  • Entenderás mejor las necesidades específicas del cliente.
  • Comprenderás mejor cómo este usa el producto.
  • Manteniendo una actitud abierta, podrás recibir sugerencias de mejora que nunca se te habrían ocurrido.

En definitiva, dejas que los usuarios de tu producto (que además pagan por él directa o indirectamente) lo moldeen en cierto sentido para ajustarse mejor a las necesidades que tienen.

Como desarrolladores, en ocasiones se nos olvida que no programamos un producto o proyecto para nosotros mismos, sino que lo hacemos exclusivamente para que otros lo usen para resolver algún problema en particular. El cliente o usuario, en definitiva, es quien tiene la última palabra para validar si lo que se le entrega está bien, mal o es una solución más bien mediocre. Sin usuarios contentos, no hay producto (obviedad), y tampoco nadie que pague por nuestro trabajo (otra obviedad).

No siempre es fácil reconocer que algo en lo que se ha estado trabajando mucho tiempo, al final no sirve para nada (porque ningún usuario lo utiliza). Tampoco solemos tener una actitud suficientemente abierta como para encajar críticas que nos suenan negativas.

En el último año he tenido experiencias al respecto bastante buenas. Desde hace tiempo, uno los productos que comercializamos en la compañía para la que trabajo (y cuyo desarrollo lo he liderado yo desde el primer momento) ha evolucionado y crecido, básicamente, con el feedback activo de nuestros clientes consolidados que lo utilizan.

¿Resultado?

Me gustaría pensar que hemos ganado con esta actitud activa de escucha lo siguiente:

  • Reconocemos todas aquellas mejoras que el cliente necesita en su día a día.
  • Este feedback en realidad es una información valiosísima que nos permite generar un producto más cercano aún a las necesidades de ese mercado en particular.
  • El cliente se siente valorado al tenerse en cuenta sus sugerencias.
  • El producto evoluciona, por tanto, los clientes sienten que están usando (y pagando) un producto que mejora con el tiempo.

Del mismo modo, es difícil a veces saber identificar aquello que ese cliente solicita y que es muy particular y específico de aquello que realmente se puede incorporar como nueva funcionalidad útil al producto.

Esto es realmente lo que se persigue con una aproximación lean al sacar nuestros productos, tal y como lo describe Eric Ries en su libro El Método Lean Startup.

Son muchas las experiencias que se cuentan sobre la aproximación MVP (minimum viable product) para la generación de nuevos productos y la validación de ideas. Es decir, antes de dedicar mucho esfuerzo al desarrollo de algo que crees que va a funcionar, primero sacas un simple (y barato) prototipo para que lo valide tu entorno más cercano (que perfectamente pueden ser amigos y familiares). Con la información que recabes de ellos vas a validar tu hipótesis sobre la idea inicial o no; en caso negativo, también tendrás suficiente información como para abandonar esa idea (porque a nadie le interesa) o pivotar, es decir, evolucionarla para ajustarla mejor a una base mayor de posibles usuarios o clientes.

Podemos ser magníficos desarrolladores de software y crear soluciones limpias, evolucionables y maduras, pero si nadie las usa, entonces todo quedará en un bonito e inútil ejercicio o pasatiempo de fin de semana (con muchas horas de esfuerzo derrochadas e inútiles). De ahí que me interesen tanto todos esos aspectos que rodean el éxito de un producto software, sea éste del tipo que sea, una aplicación pesada de escritorio, un portal web o una aplicación móvil.

Recientemente me he acordado mucho de esto al leer Vender es Humano (de Daniel H. Pink); este es un libro muy interesante que recomiendo y que considera la venta como algo consustancial a cualquier actividad que realizamos. Todos, en el fondo, somos vendedores de algo, es decir, necesitamos usuarios o clientes que paguen por lo que hacemos. Venderemos más y mejor si además mantenemos una actitud abierta de escucha y si alentamos y recibimos con agrado cualquier tipo de feedback.

Durante el trabajo escribiendo El Libro Negro del Programador y después de su publicación (hace ya medio año), he recibido multitud de mensajes, sugerencias y observaciones. Todos esos comentarios me ayudaron (y lo siguen haciendo) a mejorar lo que hago, pero algunos de ellos me dieron bastante que pensar.

En concreto me indicaban que por fin se escribiera afortunadamente en castellano un libro en el que se recogieran el tipo de experiencias que trato en él y se hablara explícitamente de clean code, refactorings, etc, lo que me chocó bastante con la suposición de que los desarrolladores de software, programadores, analistas, informáticos en general, tengan un dominio suficiente del inglés como idioma en el que se encuentra gran parte de la literatura técnica que abarrota nuestras estantarías.

Pues bien, esa suposición no es del todo cierta y muchas veces lo que se pretende es poner en el currículum lo que se espera poner en él. ¿Habéis visto alguna vez un currículum en el que alguien no ponga eso de "nivel medio de inglés hablado / escrito"?

Unos meses atrás tuve en la oficina donde trabajo dos becarios que durante un tiempo hicieron con nosotros sus prácticas. Reconocían que les costaba mucho leer en inglés y que además preferían mil veces leer posts o libros en español.

No estoy hablando de que se ignore que nuestra profesión esté dominada por el inglés y que si queremos ofrecer nuestros servicios en un mercado global, necesariamente, sí o sí, hay que hacerlo en ese idioma. De lo que se trata es de reconocer que existe un enorme vacío de contenidos técnicos de desarrollo de software de suficiente calidad y de prestigio en nuestro idioma materno, y precisamente por ello existe una gran oportunidad para llenarlo.

En mi opinión, la razón por las que no existe un mercado auténticamente desarrollado de literatura técnica en castellano escrito por y para hispanohablantes (y no simples traducciones que en ocasiones son muy defectuosas y caras) es que no asociamos la estrecha relación que existe entre ser bueno o muy bueno en tu profesión y dedicar parte de tu tiempo a enseñar a otros sobre lo que mejor sabes hacer.

Nos falta dedicar más tiempo a enseñar y hacerlo como algo natural y como parte de nuestra profesión.

Como se suele decir, no sabes algo hasta que no eres capaz de explicárselo a tu abuela. Esta semana sin ir más lejos, le estuve mostrando a mi hija mayor cómo hacer un sencillo programita con javascript (en NodeJS) para sumar y restar, y reconozco que me costaba mucho trabajo explicar cosas para mí tan fundamentales de la programación que casi no reparamos en ellas. Entre otras cosas, me preguntaba que si para hacer ese programa para sumar se necesita otro programa (el editor de texto más el que lo ejecuta, y a su vez estos se hacen con otros programas), entonces ¿quién hizo el primer programa?...

Desafortunadamente, me encuentro con que muchos de los que sí escriben algo en forma de posts, aparte de que no les dan una continuidad y a los pocos meses el blog está completamente abandonado, lo hacen porque se sienten un poco obligados a hacerlo o para obtener cierto tipo de prestigio..., pero no por una vocación auténtica de enseñar o compartir.

Nos falta una auténtica cultura de compartir aquello que mejor sabemos hacer, sea esto lo que sea para cada uno. El conocimiento, si se guarda tras una coraza, termina devaluándose, cuando en realidad se amplía al compartirlo con otros. Estoy convencido de que existe una relación entre tu solvencia técnica y tu capacidad de mostrar y enseñar lo que sabes hacer bien.

Ya escribí en El Libro Negro del Programador un capítulo relacionado y titulado "Esclavo de tu propia solución o cómo querer ser imprescindible", acerca de cómo en entornos laborales en donde la competencia entre tus propios compañeros es palpable, se tiende erróneamente a intentar crear tu propia parcela de dominio (y que con el tiempo termina convirtiéndose en una auténtica jaula perdiento oportunidades).

Personalmente he aprendido mucho más escribiendo y compartiendo los capítulos del libro que si sencillamente nunca me hubiera parado a escribir sobre esos temas.

Se aprende leyendo libros, claro está, viendo videos, hablando sobre los temas que te interesan, pero también escribiendo, lo que es una aproximación distinta a ese conocimiento pero que te permite profundizar en él.

La percepción que tengo es que es un buen momento para liderar proyectos y escribir en castellano textos de calidad relacionados con tecnologías software. Afortunadamente, ya no hace falta contar con el premiso de ningún grupo editorial para que la obra, si es buena, se divulgue rápida y viralmente por Internet y te permina tener éxito.

Del mismo modo, creo que existe un gran número de desarrolladores de software que no dominan el inglés suficientemente y que si contaran con mejores contenidos en español, tendrían entonces una mejor formación y motivación para ser aún mejores en su profesión. Lo que quiero decir es que si el mundo anglosajón cuenta con muchos más proyectos de éxito (y más sonados) y en el mundo hispanoparlante no, puede estar relacionado con la ausencia de contenidos formativos de calidad en nuestro idioma.

¿Oportunidad? ¿Posible fuente de nuevos proyectos? Quién sabe, pero desde luego lo que sí es cierto es que si existiera un magnífico portal en nuestro idioma como sitepoint.com, con buenos contenidos, por poner un ejemplo, muchos de sus usuarios hispanoparlantes no dudarían en usarlo.

Ningún gran proyecto avanza significativamente de un día para otro. Todo, absolutamente todo, se realiza después de finalizar cientos de tareas aparentemente pequeñas.

Me gusta ver los proyectos de esta forma: como un conjunto de tareas de pequeña dimensión que se pueden hacer en cualquier momento pero que cuando nos damos cuenta, su suma nos permite obtener un buen resultado, algo apreciable.

No en vano todas aquellas personas que aparentemente consiguen muchas cosas son las que precisamente saben cómo dividirlas en pequeñas tareas y que además mantienen la disciplina de ir realizándolas poco a poco. Dividir en tareas y tener la disciplina de realizarlas, para mí aquí está la clave para conseguir buenos resultados.

No es fácil dividir cualquier asunto en partes que se puedan realizar discontinuamente; sin embargo en eso consiste también la capacidad de afrontar en el día a día muchas responsabilidades de naturaleza distinta.

¿No es así acaso como programamos o desarrollamos un proyecto software? Quizá estamos acostumbrados a dividirlos por fases, requisitos o historias de usuario, en esencia es lo mismo. Dividimos algo grande en paquetes ordenados de modo que cuando la mayoría comienzan a estar terminados y colocados en orden, comenzamos entonces a ver un resultado tangible.

The Compound EffectHace un tiempo leí un pequeño libro que trataba precisamente de esto: en El Efecto Compuesto de Darren Hardy se afirma que todo lo obtenemos como resultado de pequeños pasos pero que se acumulan con el tiempo, desde la creación de buenos hábitos hasta cualquier proyecto personal. Esta percepción va en contra de la tendencia habitual de querer obtenerlo todo rápido y sin esfuerzo. La mayoría de las cosas no funcionan así: detrás de muchos proyectos que admiramos, sin parecerlo, existe un enorme trabajo por detrás, tanto de puesta en marcha como de planificación, organización, de marketing, etc.

A veces te sientes abrumado porque tienes en marcha muchas asuntos de naturaleza distinta: la clave para asumirlos y que terminen con éxito es saber dividirlos en pequeñas tareas y priorizar su realización con una buena organización. 

No sé si de la mejor manera posible pero así yo llevo años emprendiendo fuera de mi trabajo full-time intraemprendiendo en el mismo, sabiendo que ciertas cosas van a llevar mucho tiempo pero que si no se realizan paso a paso y poco a poco, desde luego que se quedarán por el camino y además con un buen varapalo de frustración.

Entre las muchas cosas que tengo en marcha, tengo un proyecto entre manos que seguramente vea la luz dentro de un año; la forma de realizarlo, en este punto del post ya debe ser evidente: identificando multitud de tareas que puedo escalar en el tiempo. Algunas me llevan media hora, otras un par de horas cuando sé, quizá una tarde de sábado, que tengo ganas y tiempo para meterme de lleno en ellas. Eso sí, todas las semanas termino 100% las que la semana anterior me he propuesto, aunque me quite horas de sueño (= disciplina). De este modo, desde el verano en que lo comencé, ya empiezo a tener cerca el momento de liberar un MVP (minimum viable product) que me permita contrastar en mi entorno cercano (incluida la compañía para la que trabajo) su viabilidad o utilidad.

El trabajar de este modo en cualquier entorno, en tu día a día en tu empresa o en cualquier proyecto personal, tiene además las siguientes ventajas que no son fáciles de apreciar al principio:

  • Dividir cualquier trabajo en pequeñas tareas te sirve para valorar en cierta medida el esfuerzo que se va a necesitar para terminarlo.
  • Te permite planificar y organizar mejor.
  • Saber qué tareas son más importantes en relación con otras menos relevantes: puedes priorizar.
  • Si se está poniendo en marcha alguna nueva idea, el traducirla en tareas te permite definirla, afinarla y pulirla mejor.
  • Se genera una gran satisfacción al terminar una tarea: tienes sensación de progreso.

El día sólo tiene 24 horas, de ella trabajamos durante una parte y de esa parte se suele perder demasiado el tiempo por no tener un conjunto claro de tareas en las que avanzar. En la batalla del día a día es difícil ver las cosas con una perspectiva a más largo plazo, de ahí que el progresar en las responsabilidades mediante tareas más pequeñas e individuales nos permita aumentar la productividad (que no es más que hacer más en menos tiempo).

Páginas

Mis libros en todas las tiendas:

Amazon
Google Play
Apple
Kobo
Barnes and Noble
Scribd
Smashwords
Payhip
Gumroad

Rafael Gómez Blanes Rafael Gómez Blanes
¿Hablamos?

 

Trabajo en...

Archivo

Mis novelas...