Podando el árbol del conocimiento

arbol

Durante agosto he reducido mi lista de lectura de Pocket de 150 a tan solo 98 artículos (los más densos). Aún tengo horas de video de YouTube y Channel9 por ver, cursos pendientes por hacer en Microsoft Virtual Academy, Lynda (LinkedIn Learning) y Alison y docenas de libros y artículos por leer en PDF o papel.

No es que no lea, haga cursos y vea videos, es que no consigo hacerlo con la velocidad suficiente como para reducir su número. Llevo cerca de un año intentando reducir esas cifras, particularmente en Agosto, pero solo consigo frenar su aumento, que no es poco.

Revisando este blog es evidente que se trata de problema que está ahí desde hace tiempo, pero últimamente está empeorando debido a los múltiples roles que desempeño gracias al crecimiento profesional de mis últimos años: arquitecto de software, team leader, gestor de servicio, coach… Cada uno de ellos con unos requisitos de conocimientos y habilidades diferentes que no hacen sino ampliar el problema.

Entiendo que el origen de esto, no es tanto la cantidad de cosas que aparecen o toman relevancia en el plano técnico, como mi crecimiento profesional, mi dedicación a mi familia y mis años de experiencia y conocimiento acumulado. Esto último me hace más consciente ahora sobre lo que no sé en diversos dominios: tanto más allá de Microsoft, como más allá del desarrollo puro y duro. Otros han hablado ya del síndrome del impostor, pero este post no va de eso.

Creo que es momento de aceptar la realidad y dejar de nadar contra la corriente para empezar a navegar con ella. Dicho de forma menos poética esto implica reducir mi espectro de “intereses” y empezar a eliminar todo lo que no pueda traducirse en una mejora importante de mi vida. En particular, el tiempo que dedico fuera del trabajo a aprender o mantenerme al día debe tener una razón de peso para hacerlo y un impacto tangible. Por ejemplo, mi actividad en SwCraftersCLM continuará porque me carga las pilas aportar a una comunidad de forma directa y desinteresada. Además me pone en contacto con gente, problemas y soluciones fuera de las burbujas de Microsoft y Madrid, que siempre es algo bueno.

Escribo este artículo para obligarme a parar a pensar en este problema y en posibles soluciones; para ayudarme a seleccionar qué se queda y qué se va de todo ese conocimiento que tengo en cola; y para seleccionar una ruta más concreta de aprendizaje que mejore mi futuro.

Provisionalmente la lista de temas importantes para continuar aprendiendo o trabajando, es esta: Soft skills para mejorar lo que hago con personas, Arquitectura de Azure para no quedarme desactualizado al ritmo que lleva la nube en la que trabajo actualmente y Blockchain porque parece la tecnología con más potencial de los últimos 20 años… y además puede trabajarse en Azure.

NOTAS:

Dado que uso este blog como una bitácora donde apunto temas que quiero tener a mano en el futuro, he podido revisar mi proto visión de este problema a lo largo de los años (años ’10, ’11, ’12, ’15 y ’16).

Reproduzco aquí algunos extractos por si alguien tiene interés o ve paralelismos con sus propios problemas y le ayuda a resolverlos:

El mundo del desarrollo con Microsoft, a pesar de todas las facilidades, potencia y posibilidades de integración que ofrece, puede llegar a hacerse bastante cuesta arriba cada vez que sale una nueva versión de sus productos, algo que sucede, para bien o para mal, muy a menudo.

[…]

tenía ganas de soltarlo y pararme a pensar un rato sobre ello, porque el reciclaje constante, el cansancio acumulado gracias a mi pequeña Celia, y los proyectos pueden llegar a hacer pesados los días de I+D con límite de tiempo, y eso hay que atajarlo si no se quiere acabar con un síndrome de burnout.

Desde <https://jbolano.wordpress.com/2010/01/28/reflexion-sobre-el-desarrollo-de-software-tecnologias-y-herramientas-reciclaje-extremo/>

siempre hay que estar aprendiendo, pensando y probando, nunca puedes “apalancarte” y muchos acaban quemados o abandonando lo que parece una carrera de ratas. Al final los que quedan, son probablemente los que más y mejores soluciones conocen (por mera experiencia) y eso debería hacerlos valiosos por encima de modas.

Desde <https://jbolano.wordpress.com/2011/12/18/toma-de-decisiones-y-desarrollo-de-software/>

“¿cómo arreglamos este gap, este abismo de conocimientos que está cargándose la viabilidad de mi empresa?” La respuesta es, en mi opinión, que no se puede resolver, solo podemos tratar de minimizar el problema. Y para minimizarlo, al margen de reconocerlo en nosotros (sí, todos lo tenemos, no se libra ni Dios) y en los demás, debemos tratar de atacarlo a la mínima oportunidad: si vemos que nuestros compañeros desconocen algo o realizan tareas que debería estar realizando una máquina, debemos acercarnos y ayudar con ello. Se requieren también paciencia, curiosidad y humildad para reconocer nuestra propia ignorancia y ocasional estupidez. Y se requiere una voluntad de equipo para tratarla entre todos en el día a día, a pesar del estrés, los roces y los humos de cada uno de nosotros. Pero sobre todo, creo que se requiere valor y asertividad para cuestionarlo todo (independientemente de la jerarquía) y disentir públicamente.

¿Difícil? Sí. ¿Incómodo y desagradable en muchos casos? Desde luego. Pero la alternativa dada la velocidad de los acontecimientos, es el fracaso a medio y largo plazo. Y si no, que se lo digan a la industria musical (barrida por iTunes y el P2P), la industria del cine (barrida por Megaupload y los torrents) o la industria editorial (barrida por Amazon y los ebooks) entre otras afectadas por no tener un marco de conocimientos adecuado sobre la tecnología y las herramientas.

Desde <https://jbolano.wordpress.com/2012/08/14/el-abismo/>

el desarrollo de software ha pasado por muchas etapas en un periodo de tiempo muy comprimido y en cada una ha ido ganando complejidad, añadiendo capas de abstracción y mejorando todo lo existente anteriormente de manera fulminante (a ver quién se acuerda de Word Perfect, Altavista o Myspace). Y durante ese viaje, los desarrolladores hemos ido aprendiendo por las malas que cada problema es muy distinto y requiere distintas aproximaciones

Desde <https://jbolano.wordpress.com/2012/09/27/una-breve-historia-del-desarrollo-de-software/>

Creo que todas estas son buenas razones para esperar unos tiempos la mar de interesantes en todos los frentes, y estoy deseando ver qué pasa y cómo reaccionan competidores y mercados. Ver qué falla y que arrasa, y por supuesto qué más se saca todo el mundo de la manga.

Desde <https://jbolano.wordpress.com/2012/10/22/el-desembarco-de-normandia/?preview=true&preview_id=2446&preview_nonce=0f8b62d27f>

Para terminar solo quiero dejar una última reflexión: cuando veo desarrolladores que se enfrascan exclusivamente en su tecnología de trabajo actual y por falta de tiempo o curiosidad, saben poco o nada de otros campos, herramientas y tecnologías, pienso que es poco probable que sean capaces de aportar ideas nuevas y por lo tanto de evolucionar y mejorar. Y eso es malo para todos.

Desde <https://jbolano.wordpress.com/2015/03/22/reflexion-analogias-experiencia-directa-y-desarrollo-de-software/>

muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos cómo se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

Desde <https://jbolano.wordpress.com/2016/12/09/developer-timeline-1996-2016/>

Anuncios

Developer Timeline 1996-2016

pope-john-paul-ii-and-fidel-castro-watching-time

Hace unos meses intenté convencer a algunos desarrolladores de que necesitaban aprender Git. Algo que desde mi perspectiva parecía obvio y urgente se tornó, pese a mis esfuerzos por argumentarlo, en imposible. Desde entonces he estado dándole vueltas al tema de la obsolescencia de las herramientas, técnicas y servicios que los desarrolladores usamos a diario y a como alternamos entre lo malo conocido y el hype del momento.

Esto me llevó a pensar en cómo “de-mostrar” a determinados perfiles técnicos de la necesidad de actualizarse, lo cual me condujo a confeccionar una “línea de tiempo” o mapa de tecnologías y herramientas de desarrollo .NET para poder observar el avance en determinados ámbitos como el control de versiones de código.

Gracias al intercambio de ideas de los Meetups en SwCraftersCLM y los ánimos que me han dado desde esta comunidad para publicar el “timeline de desarrollo”, he terminado una versión 1.0 que he colgado en Google Sheets para uso y adaptación de otros equipos de desarrollo, incluso de otros stacks tecnológicos. O aprovechando que acabamos el año, para pararse a pensar qué aprender en 2017.

El Excel es el siguiente: Developer Timeline 1996-2016

¿Para qué sirve?

La idea es poder usar la hoja como herramienta de 4 formas diferentes para varios objetivos:

  1. Para poder revisar en qué punto estamos de actualización técnica y ayudarnos a decidir si aprender o no una tecnología en concreto.
  2. En grupos de desarrollo. Para poder argumentar con datos objetivos frente a nuestros compañeros sobre la necesidad, o no, de reciclarnos tecnológicamente. Como mínimo debería facilitar el diálogo sin caer en el flame.
  3. En charlas. Para poder hacer una introducción simpática para todos los públicos sobre determinadas tecnologías como Core o SharePoint Framework añadiendo un contexto tecnológico más amplio que facilite el entendimiento de los problemas que resuelve.
  4. En organizaciones. Para poder establecer el nivel de actualización de una organización (la nuestra u otras) de una forma más o menos objetiva. En última instancia podría ayudarnos a decidir si embarcar en una empresa o desembarcar de la actual.

¿Qué contiene?

La hoja contiene varias categorías (eje vertical) y eventos relevantes para cada una de las categorías, repartidos por año (eje horizontal).

Me pareció adecuado empezar en 1996 por tener un intervalo amplio y “redondo”: 1996-2016. El año 1996 sirve además para poder establecer una línea base de “desarrollo viejuno”.

La información que contiene está orientada por mi experiencia y entornos de trabajo a lo largo de los años por lo que hay bastante de Microsoft, pero he tratado de mantenerlo flexible para poder adaptarlo a otros entornos aglutinando la mayoría de elementos específicos de Microsoft en su propia categoría.

Sobre las categorías, los datos y la selección

Hay muchos elementos que podría haber metido pero que finalmente he eliminado por claridad (versiones, irrelevancia…) y simplicidad.

Muchas fechas son aproximadas y en algunos casos discutibles. En general he tratado de tomar las más importantes como por ejemplo productos release en lugar de beta.

Hay bastante tecnología Microsoft debido a mi propio background y el público al que lo he enfocado, pero he tratado de mantenerlo flexible para otros stacks.

Este documento no pretende ser canónico, sino una herramienta ilustrativa de la evolución y periodos que vivimos los desarrolladores de software. Está pensado para ser modificado de forma sencilla por lo que he desistido (de momento) de hacer un gráfico SVG interactivo con D3 y JSON.

Las categorías en que he agrupado los eventos son las siguientes:

  1. Papas: Los papas de la Iglesia Católica Apostólica y Romana que hemos tenido desde el 96. Me parece interesante mostrar que hasta las organizaciones más antiguas y tradicionales experimentan más cambios que algunas personas o empresas.
  2. Efemérides: Evento de relevancia nacional o mundial. Permite replantearse la cantidad de tiempo que ha pasado entre tecnologías y los grandes cambios que han sucedido en la sociedad.
  3. Películas: Estrenos de cada año. Me parece un detalle simpático para tratar de poner en contexto el tiempo que ha pasado, en particular entre fans de Marvel como yo, y la cantidad de proyectos que pueden llevarse a cabo en 5 o 10 años.
  4. JavaScript: Aun hay gente que no quiere saber nada de JavaScript o quiere quedarse en la versión del ’99. Visibilizar la cantidad de hitos que ha tenido debería facilitar el NO poder ignorarlo.
  5. Autenticación y Autorización: Todavía tengo que explicar las diferencias entre autorizar y autenticar. En el panorama actual y dado que es necesario conocer estos temas para realizar cualquier aplicación moderna, me parece grave y por eso le he dado su propia categoría.
  6. Servicios web: Esta categoría trata de servicios web y trata de poner de manifiesto que la diferencia entre SOAP y REST en realidad son pequeñas y que deberíamos mirar más allá del hype al evaluarlas. También pone en el mapa los webhooks, que parece que son grandes desconocidos a pesar de su utilidad y antigüedad.
  7. Formatos de datos: Me pareció apropiado añadir esta categoría tras la de servicios web para señalar que son dos cosas independientes y que ya va siendo hora de aprender a usar JSON. O usar Markdown en lugar de HTML en según que contextos.
  8. Front End: Esta categoría podría ser una hoja aparte, pero he tratado de incluir estándares de facto y orientarme a desarrolladores back o full stack. He añadido asteriscos a temas de W3C para recordar que… “es complicado” asegurar en qué estado están.
  9. Gestión de código: Esta es la razón por la que comencé a confeccionar el Excel y por eso tiene un componente “fuerte” de productos Microsoft, pero dejando claro que el estándar a día de hoy es Git. De hecho, es importante mencionar que Microsoft lleva años migrado todo su código abierto a Github.
  10. Servicios de terceros: Incluyo una lista de servicios de terceros relevantes para perfiles técnicos. Estos deberían contrastar con la antigüedad de algunas de las herramientas de algunos técnicos. Si, por ejemplo, alguien usa Dropbox (2008) o Google Drive (2012), no podrá argumentar que Git es demasiado moderno (2005).
  11. Microsoft Stack: categoría específica para los que usan el stack de Microsoft, por lo que en adaptaciones a otras empresas debería adaptarse. El “baseline” es Outlook porque me pone nervioso ver que no se sabe usar a nivel básico (carpetas, convocatorias, respuestas automáticas…) y es una herramienta que todos usamos a diario para trabajar en empresas, en particular con el stack Microsoft.
  12. S.O.: Sistemas operativos desde el ’96. Con especial detalle en el ámbito Windows, claro. Porque todavía hay quien quiere volver a W7 por pura resistencia al cambio.
  13. Dispositivos Móviles: He tratado de sintetizar el panorama en dispositivos móviles. Al estar tan unidos hardware y software he mezclado ambos elementos. Evidentemente Windows Phone/Mobile se queda fuera.
  14. Lenguajes: Es interesante ver que los lenguajes de back-end son bastante estables, pero no inmutables.
  15. Entorno de ejecución: Parece que todo es alguna variedad de la máquina virtual de Java o el que tiene que funcionar sobre el CLR de .NET y no solo no es así, sino que el panorama parece que va a cambiar cada vez más. Estuve tentado de introducir Docker también, pero los contenedores son otra historia y aun me parece pronto para añadirlos, quizá el año que viene o quizá en otra categoría de DevOps.

Como nota curiosa no he notado nada interesante en 2003 pero si muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos como se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

En resumen

Como decía el personaje de Will McAvoy en The Newsroom: El primer paso para resolver un problema es reconocer que hay uno (minuto 5:00, pero el speech completo es impresionante).

Mi intención inicial era mostrar como Git es una herramienta indispensable para el desarrollador de .NET de hoy, comparándola con eventos relevantes del pasado reciente de forma objetiva y amigable.

Aunque parece que he conseguido construir esa herramienta, creo que he generado algo más potente, una especie de minicuadrante de Gartner del desarrollador .NET (y en general) que podría servir para animar a algunos técnicos a reciclarse, y que me ha ayudado a ampliar mi visión estratégica para 2017 así como a mejorar mi planteamiento como arquitecto de soluciones y líder técnico. O como mínimo me ha aclarado panorama bastante ahora que parece que todos andamos perdidos de stack en stack y de framework en framework especialmente en el mundo Microsoft.

Para terminar

Al revisar mis propios artículos me parece reconocer que en el universo Microsoft, 2016 es una repetición de 2012. Da para otro artículo, pero si estás más o menos al día creo que podrás ver las semejanzas entre el panorama actual (Azure, Office 365, Hololens, ARM, Open Source…) y el que describí en 2012 en: El desembarco de Normandía.

Y si te ha interesado este artículo, es muy probable que te interesen mis artículos: Breve historia del desarrollo de software de 2012 y mi predicción sobre el futuro de Blackberry, iPhone y Palm en 2007: La muerte de Blackberry.

Las dos palabras que todo profesional debería usar más

Hace unos días, Manuel de la Peña twiteó un texto que comentaba una vieja historia (más bien fábula) de monos, jaulas, preguntas y procedimientos.

Eso me trajo a la memoria pequeño artículo que leí en Hardvard Business Review sobre el arte de hacer preguntas. Un artículo que en su momento me invitó a pensar en la importancia no tanto de las técnicas de hacer preguntas, como de lo esencial que es conocer el “por qué” de las cosas (y para lo que se necesita hacer preguntas, claro).

También me recordó este otro artículo sobre qué hacen las personas que son buenas escuchando y que en mi opinión es una consecuencia de interés genuino en entender los “por qué“.

La falta de interés y esfuerzo en tratar de entender las cosas, sus objetivos y contextos (esto es, el “por qué“) es un tema que me da mucha rabia observar (incluso en mi) y del que hace tiempo que tenía pendiente quejarme un poco en público. En público, porque tiene relación directa con todos los procesos que se realizan en cualquier empresa; también con las buenas prácticas (best practices) que parece que muchas personas se emperran en recomendar o exigir sin entender que dependen del contexto. Y por supuesto porque tiene que ver con los que critican (y criticamos) decisiones de terceros a nivel personal, de negocio o político casi a diario.

Hay por supuesto profesiones en las que en general se necesita hacer preguntas básicas constantemente de forma directa o indirecta, como en medicina (¿le duele aquí?, ¿puede caminar?), donde cada prueba médica es una forma de pregunta y cada mirada o toque está orientado a obtener una respuesta (el ojo clínico). Supongo que haber tenido un padre médico ayuda a ver ciertas cosas de cierta manera.

No obstante, la mayoría, durante la mayor parte del tiempo observa, juzga y condena sin conocer el “por qué” de una decisión. Pocos se molestan en hacer preguntas la mayor parte del tiempo. Mucho menos una tan básica como “¿por qué?“. Y desde luego nunca seguida de otro “¿por qué?” como en el método Toyota-Lean-Kaizen-Six Sigma de los 5 por qué para la mejora de procesos.

Me temo que hemos cogido miedo a hacer preguntas básicas, las más importantes, por miedo a parecer ignorantes y menos valiosos en nuestro entorno personal y puesto de trabajo, e irónicamente eso nos hace más ignorantes y menos valiosos.

Pero no acaba ahí el problema: como nadie hace preguntas para entender un contexto todos acabamos dando por sentado que este no importa y/o que todos tenemos la misma idea en la cabeza, lo que provoca errores y dificultad en la comunicación. Un desastre.

En fin, que las dos palabras que creo que todos deberíamos usar más son evidentemente “¿por que?”. Aunque hay otro par de palabras que, si se usasen con sentimiento real, también deberíamos usar más y mejoraría mucho nuestras vidas: “por favor”. Porque es sorprendente lo bien que responden algunas personas a un poco de interés y educación y como redunda eso en un win-win de libro.

Así que tras quejarme un poco y habiendo dejado algunos enlaces (espero) interesantes, solo puedo cerrar este post invitando a todos a preguntar más y mejor. Con inocencia y abiertos a escuchar.

Productividad: Contexto y priorización de proyectos

Nota: tenía esto guardado desde 2013, pero por alguna razón olvidé que estaba en el cajón de “para publicar” hasta la limpieza de enero de 2016.

En mi carrera como desarrollador me he encontrado bastante a menudo, supongo que como todos, con una cantidad excesiva de proyectos sobre la mesa y por eso me gustaría comentar una estrategia para abordarlos que, sin ser mágica, me permite establecer un flujo de trabajo operativo.

Empezaré aclarando que pienso que la abundancia de proyectos es por un lado algo bueno, porque significa que voy a tener trabajo durante un tiempo (hola Crisis), pero por otro lado, resulta que me encargo de casi todas las funciones de cada proyecto por lo que soy yo quien debe organizar mi propio tiempo (al menos cuando me lo permiten) no solo entre proyectos sino entre tareas del proyecto… y rendir cuentas y plazos.

Así que ahí estoy, el equipo de un solo hombre, viviendo fuera de mi zona de confort (habilidades técnicas variadas VS sociales, de gestión, de comunicación, de diseño…), y tratando con una miríada de proyectos concurrentes. Y con todos estos cambios de sombrero, entorno, tecnología y negocio, sufro de manera crónica los cambios de contexto. Cambios que se cargan la productividad, claro.

Los cambios de contexto

Todo el que haya trabajado (de verdad) en varios proyectos a la vez, sabe que un cambio de contexto, supone “sacar” de la cabeza todo lo que tengas sobre una tarea X y llenarla con la tarea Z que quieras acometer. A mayor complejidad del proyecto, y a mayor número de elementos implicados (gente, documentación, herramientas, productos…), mayor es el tiempo empleado en cambiar de contexto, especialmente si además se trata de proyectos en áreas de negocio diferentes (cine, logística, auditoría legal, banca de inversión, marketing…). Algunos autores calculan una media de 20 minutos perdidos por cada interrupción en un trabajo intelectual que requiera concentración, pero personalmente creo que los cambios de contexto entre proyectos donde uno se encargue de casi todas las áreas, que además sean de áreas muy diferentes, y que impliquen un gran número de herramientas diversas, suelen ser mucho más pesados que una interrupción media, precisamente por las dimensiones de roles, ámbitos, conocimientos y entornos que se añaden al problema. Y todo esto sin entrar a comentar el desgaste intelectual de todo esto.

Estimemos por ejemplo 10 días para un proyecto corto, luego contemos que cambias de proyecto (por la razón que sea, no por capricho) 2 veces al día. Con esas cifras tan pequeñas es fácil calcular, siendo muy conservador y usando la media de 20 minutos, que acabaré acumulando (10 días x ((20 minutos x 2) / 60)) más de 6 horas de pérdidas. Un cálculo completamente ficticio y en bruto, pero que sirve para poner de manifiesto que los cambios de contexto tienen un coste que no se suele tener en cuenta, y que por tanto deben ser evitados en lo posible, si no queremos provocar una caída a plomo del trabajo efectivo realizado.

El método

Con esta idea en la cabeza, a lo largo de los años he desarrollado un flujo de trabajo que, si bien tiene sus propios problemas, sí me permite ser más productivo y reducir los cambios de contexto. Y lo que es más importante, lo hace sin que tenga que pensar o decidir demasiado.

El método es este:

  1. Trabajar únicamente en el proyecto que tenga la estimación de tiempo más corta e ignorar en lo posible los demás. A menos proyectos en marcha, menor es la probabilidad de tener que cambiar a uno, así que es mejor acabar los más cortos cuanto antes.
  2. Trabajo en el proyecto de los clientes que pagan. Si un cliente es de los que tardan en pagar, o de los que ponen pegas durante meses (no me meto en si con razón o no), su proyecto queda en cola. Esto se debe sobre todo a que un proyecto no cobrado, es un proyecto abierto, y el cliente que no paga tiene poder de imponer cambios no contemplados que alargan el proyecto de manera inesperada más allá del alcance inicial. Con esta regla, minimizo el impacto de los clientes/proyectos “malos”.
  3. Brown dispatching de tareas. Los proyectos más complejos (técnica u organizativamente, o en cualquier otro ámbito) suelen requerir de acción por parte del cliente o de terceros así que para evitar cambiar de tarea, ante una interrupción, trato ganar tiempo decidiendo lo más rápido posible si debo pasar la pelota a otra persona/responsable. Por ejemplo: si hay una incidencia en una aplicación, pido datos, pantallazos, etc; si me piden información, les mando al repositorio del proyecto a buscar (SharePoint es tu amigo); si me piden una reunión, les digo que mañana, que pongan ellos la hora. Y así con todo, bajo la premisa de evitar el cambio de tarea o postergarlo al mañana, cuando el cambio de contexto casa/trabajo es inevitable (hay que dormir) y el daño producido es menor, aunque no evitado.

Obviamente, estas técnicas tienen su propia problemática y en ocasiones no es factible utilizarlas, pero al menos ayudan a NO tomar decisiones y reducir los cambios de contexto, por lo que mejora la productividad y reduce el cansancio asociado a la toma de decisiones, que como sabemos, en el desarrollo de software es algo agotador.

 

Este año, sé un héroe

En 2012 no me decidí a publicar esto debido a su escasa longitud. Se trata de un texto que traduje de Philip Zimbardo acerca de las acciones heroicas en el contexto de su proyecto Heroic Imagination. De cómo podemos mejorar la sociedad.

Creo que el inicio de este año y dada la situación actual nacional y mundial, es un buen momento para recordarlo.

Una acción heróica es:

  1. Iniciada voluntariamente;
  2. Realizada en servicio de una o más personas o de la comunidad como conjunto;
  3. Involucra un riesgo al comfort físico, estatus social, o calidad de vida;
  4. Se inicia sin la expectativa de una ganancia material

Los heroes reactivos son personas que actuan en el momento, usualmente de manera espontánea. Tras lo cual, un heroe reactivo a menudo dirá algo como “no tuve tiempo de pensar, simplemente lo hice.”

Un heroe proactivo es alguien que realiza continuos esfuerzos a lo largo del tiempo para exponer operaciones de fraude, montajes, o corrupción. Tales heroes son más efectivos cuando forman redes con otros que comparten sus valores, atenuando por tanto las críticas (de defensores del sistema malvado) de que son fanáticos o están equivocados.

Texto original:

Heroic action is:

  1. Engaged in voluntarily;
  2. Conducted in service to one or more people or the community as a whole;
  3. Involving a risk to physical comfort, social stature, or quality of life; and
  4. Initiated without the expectation of material gain

Reactive heroes are people that act in the moment, usually spontaneously. Afterwards, a reactive hero will often say something like “I didn’t have time to think, I just did it.”

A proactive hero is someone that makes continual efforts over time to expose the operation of fraud, deception, or corruption. Such heroes are more effective when they form networks with others who share their values, thereby lessening the criticism (by defenders of the evil system) that they are fanatics or misguided.

Frameworks, pereza y productividad

WP_20150706_012

 

Un framework es un marco de trabajo. Un conjunto de cosas (tecnologías, estándares, prácticas, ideas…) que nos ayudan a realizar un conjunto de trabajos sin tener que pensar todo de cero. Una framework es una herramienta para acelerar el trabajo y reducir la incertidumbre del resultado. Pero esa misma reducción de la incertidumbre es a costa de reducir la flexibilidad de las soluciones que ofrece.

Diferentes framework están orientados a diferentes tipos de problemas o clientes. O enfocan los problemas de diferente manera, o aprovechan mejoras en la tecnología (memorias más rápidas, procesadores más potentes…) para tratarlos de diferente manera.

Si lo comparásemos con un viaje, el framework es el viaje en crucero, donde no podemos quedarnos más tiempo del establecido en ninguno de los puertos, ni cambiar de destino, ni cambiar de camarote o volver a casa cuando queramos… a no ser que paguemos un alto coste.

La incertidumbre del resultado es insignificante, pero estamos en cierto modo atrapados.

Un framework es cualquier metodología como Scrum, o la gestión de proyectos del PMI. También pueden considerarse frameworks plataformas o productos como Oracle (la base de datos con todo tipo de funcionalidad) o el SharePoint de Microsoft sobre el que yo mismo trabajo.

En desarrollo de software un framework es algo como .NET o Angular, pero no una librería como JQuery. De ahí que JQuery se pueda usar dentro proyectos ASP.NET por ejemplo: una librería es muy flexible y ofrece una solución especializada que completa otros frameworks.

Quizá cuando el cliente no sabe lo que quiere y no está interesado en pensarlo demasiado es cuando más nos deberíamos ceñir a los frameworks, de modo que el cliente esté “obligado” a seguir un guion predefinido, uno que al fin y al cabo alguien sí ha estado pensando. En caso contrario, si permitimos que el cliente dé “bandazos”, podemos acabar con un proyecto a la deriva con mucha facilidad y terminar agotando todos los recursos disponibles sin llegar a un resultado satisfactorio.

Algunos clientes sin embargo, están perfectamente preparados para asumir esa deriva y no tienen miedo a invertir recursos en el viaje. A estos no les hace falta el framework (incluso puede que les perjudique), porque han decidido que no tienen miedo a explorar y a salirse de las rutas establecidas.

Por último existe un peligro en usar los frameworks sin entenderlos. Cuando trabajamos dentro de estos, debemos tener claros sus límites y las ideas que los sustentan, así como el problema que pretendamos resolver. Si no lo hacemos, si nos limitamos a usar el framework porque sí, lo más probable es que terminemos retorciéndolo y mutilándolo hasta destrozarlo, quizá resolviendo el problema del cliente en el proceso, pero sin duda generando decenas de problemas adicionales en el proceso, empleando mucho más esfuerzo del necesario y con un resultado incierto (lo he visto en varias ocasiones).

En estos casos de uso sin conocimiento real del marco de trabajo, su uso genera precisamente el efecto contrario que se buscaba: resultados inciertos, esfuerzo extraordinario y problemas adicionales.

En resumen, el uso de un framework o herramientas de terceros debe estar sujeto siempre que sea posible a una comprensión de los mismos (para qué sirve, como ataca el problema, etc.) y en mi opinión hay dos usos muy claros para estos, siendo el resto discutibles: a) equipos con experiencia que usan su propio framework o uno específico bien conocido para resolver más o menos los mismos problemas de forma recurrente o b) personas con poca o nula experiencia que necesitan un entorno que les guíe para poder ofrecer cierto rendimiento de desarrollo.

Libro: The Germ Theory of Management

Creo que leí esto atraído por un twitt de @Aelena y ha resultado ser una auténtica joya. En realidad no es un libro sino un artículo de 20 páginas, pero se trata de una lectura lo suficientemente atractiva como para que la automarque como “libro” para futuras referencias.

Este artículo de Myron Tribus habla de los problemas sistémicos, lo que significa “Calidad” y como se relaciona todo con la gestión de empresas (o equipos si se desea).

No es habitual ver tan bien explicado como una empresa es un organismo, un sistema y como las variaciones de rendimiento entre diferentes personas o departamentos pueden ser perfectamente explicables por el azar. Y donde las medidas tomadas en una parte, afectan al todo de formas imprevisibles si no tenemos cuidado.

Tampoco es habitual ver el acento puesto en gestionar el sistema en que trabajan las personas y no en gestionar a las personas o realizar mejoras marginales sin una visión global del sistema. Llega a decir que ante un problema debería tomarse probable que el 85% de las veces, el origen es el sistema y el 15% de las veces el propio trabajador.

Me recuerda muchísimo a Zimbardo, pero hablando de gestión empresarial, y resulta especialmente interesante ver como anticipa los problemas que se darán al tratar de transmitir esta visión a quien no la ha desarrollado por otro camino: resistencia activa e incredulidad.

Por último una reflexión: si la variabilidad es mala para funcionamiento del sistema eso significaría que los desarrollos de software a medida o las implantaciones “adaptadas” (más allá de una mínima personalización) de productos informáticos en las empresas son en principio malas. Sin embargo la variabilidad, aunque puede ser mala, es necesaria para la evolución. Siguiendo con la metáfora biológica, los organismos necesitan variabilidad para sobrevivir y adaptarse y mejorar, cualquier otra opción lleva a la extinción.

Por último, una pequeña cita del artículo:

After a while some of the operators learn special tricks to apply when the aluminum rolls have to be changed. Because the management rates the operators individually and competitively, those who learn new tricks are not always willing to share them with their competitors. What the management then see is a large variability in the capabilities of their operators. They think they are witnessing the results of the variability of people; they aim to fire the “bottom half”. They do not know that the virus of variability is infecting their processes.

They act on what they know. They have an explanation for everything and are confident in what they do. In the process they ruin the lives of some of their workers. They are a menace to the health of their companies, but because neither they nor their workers understand about the virus of variability, they are unaware. They know not what they do. And they do not like to be told.