Un área TIC ágil en la administración pública (parte II)

Vuelvo con un poco más de agilidad en la administración. En la primera parte explicaba un poco cómo nos organizábamos en el área TIC de la administración pública en la que trabajo. Di un poco de contexto para que sepáis el porqué de las tonterías que voy ha decir en este y en los siguientes artículos.

En resumen, trabajo en una sección de desarrollo que se hace cargo de la gestión de todo lo que desarrolla. Intentamos usar mecanismos ágiles y DevOps en el trabajo para poder seguir siendo un área de desarrollo y no acabar absorbida al 100% por las operaciones.

Esta visión no la tienen todas las personas en el área, ni mucho menos. A mi entender, hay una falta de interés generalizado en estos temas, ya que cada persona ha tenido sus experiencias personales y tiene su propia manera de ver las cosas. Cada una ha llegado allí de una forma u otra, y estoy seguro que no querer emprender el camino para ser "ágil" se debe más a la desilusión y al haber experimentado cabreos y frustraciones, que no querer probar cosas.

Y es que en las administraciones (y en todo los lados) te encuentras con actitudes que minan la moral a cualquiera. Te cuento aquí algunas que creo que dificultan mucho abrazar el proceso de cambio:

Esto se hace en 5 minutos

Todo es fácil y no cuesta nada. Suele ir acompañada de una ausencia de cálculo de lo que les cuesta hacer cada cosa, ningún dato al que agarrarse, ninguna planificación. Normalmente se basan en sensaciones: "Esto es una tarde", "No lleva más de dos días".  

Y para nuestra desgracia normalmente fallan. Primera porqué no suelen contar todo el trabajo que hay que hacer realmente (preparar entornos, QA, seguridad, comunicación, etc) y segunda, ignoran todo el trabajo que conlleva el ignorar la primera. Llamadas, arreglos, etc.

Este tipo de actitud se puede deber a que asociamos saber hacer una cosa con qué se tarde poco. Y es que en TIC nos enfrentamos a problemas en los que antes de empezar no sabemos la solución. No tenemos ni idea de cómo se hacen las cosas. Ahora, si algo sé cómo se hace, entonces son 5 minutos.

Hay veces que ese comportamiento se debe a falta de experiencia, pero he visto bastante gente con esta actitud, que incluso te discuten si aportas datos. El problema se acentúa si por en medio hay problemas de confianza.

Entonces ¿para qué vas a calcular tu capacidad?. ¿Para qué quiero saber la velocidad de mi equipo? Y ya, ¿porqué voy a intentar hacer predicciones de lo que nos costará hacer una historia de usuario?, si la respuesta es siempre la misma: eso son cinco minutos.

Las metodologías son una chorrada

Quien dice metodologías, dice estándares, o cualquier otra cosa. Y aquí se ve claro que las malas experiencias te llevan a pensar eso. Normalmente el "hacer por hacer" te llevará a caer en ese escepticismo. Implantar ITIL, Cobit, SCRUM XP, Prince, ISO 9000, etc. Seguro que todas hemos pasado por alguna de esas. 

Si una mala implantación te obliga a hacer trabajo que no aporta valor  (muchas veces implantar sin saber que queremos obtener o dónde llegar), pues ves como todo un sistema que vas a implantar no valen para nada, y por extensión cualquier otro. Ves que tu día a día sin esa metodología es mucho más productivo. Vamos, que para estar hasta el cuello de fango mejor te estás en el tuyo. 

Pero como os digo, ahí la mala experiencia puede haber sido una falta de estrategia o una ejecución horrible. Muchas veces se ve la implantación de un modelo como un fin y no como un medio para llegar a un propósito.

Podemos ver todas esas metodologías como unas normas para trabajar de una forma determinada (incorrecta), o ver en las metodologías un instrumento forjado por experiencias de mucha gente que ha pasado por lo mismo que nosotros hace tiempo. Intentar entender el porqué de las cosas, ventajas y inconvenientes que nos aportará, y si tenemos claro que nos interesa estar ahí, entonces apliquemos nuestra versión de la receta.  

El problema es que la gente no quiere trabajar

"De haberlos, haylos", pero como en todos los sitios. Muchas veces oigo como la gente se queja que en la administración se trabaja poco. Frases como, este en la privada lo echan al primer día, las oímos a diario. Pero siento deciros (alguno se llevará una gran decepción) que en la administración se trabaja. La mayoría trabajan correctamente o incluso más de lo que deben, pero como en todas las casas hay quien no lo hace.

Es muy difícil de reconocer por una cargo directivo, que haya gente que no trabaje tenga algo que ver con la forma en qué dirigen, y la verdad es que tiene mucho que ver.

Pero al tema, cuando alguien de dirección piensa que una área TIC (privada o pública) no tiene la capacidad de trabajo requerida porqué los trabajadores se tocan parte del órgano reproductor con las dos manos, entonces estás en un sitio donde no se puede ir más allá. 

Alguien que piense eso no pensará ni en cambios organizativos, ni en pensar los flujos de trabajo, comunicación, productividad, etc. No, solo estará pensando en que debe remplazar un equipo por otro, ya está. Cualquier intento de cambiar lo verá como una pérdida de tiempo y no te ayudará.

De ahí salen miles de historietas divertidas, como que intentan proyectos personalmente, crear equipos paralelos bajo su supervisión, contratación de empresas de confianza, etc.

Si finalmente consigue cambiar el equipo, tendrá el gran placer de experimentar la misma sensación otra vez. Lo malo que seguirá sin darse cuenta del error.

Las cosas ya están bien como están

Oye, ¿no estábamos tranquilos?. A ver, todo el día me estoy quejando de lo mal que está todo y que lo quieren para ayer, pero ¿no es esto parte de la felicidad?. ¿Parece absurdo, no? Pues nos pasa a todos. Uno cuando se acostumbra al olor de su mierda ya no le huele. Las llamadas imperiosas, las urgencias, tareas no planificadas, etc. Si todo esto te sucede a diario al final entras en una relación de amor-odio. De hecho te convences de que estás ahí para eso, y que menos mal que estás tú, que sino todo se va a pique. 

Esto le pasa más a algunas personas que a otras, y la forma de llegar ahí variará en cada una de ellas, pero la verdad es que parece que padezcamos una variante del síndrome de Estocolmo. No queremos  hacer esas tareas que tienen secuestrada nuestra capacidad productiva, pero no queremos deshacernos de ellas.

Ahí tenemos que ser inflexibles. Lo que no aporta valor no interesa. Hay que hacer lo que sea para erradicar la necesidad de esas tareas.

Y hasta aquí el primer pack de actitudes que frustraran nuestro camino al cambio. Sortear personas que padecen estas actitudes es difícil. A veces las puedes cambiar, a veces lo puedes sobrellevar, pero en algunas ocasiones es uno mismo quien lleva puesta esa música sin darse cuenta. 

Huyendo del marketing

Siempre estoy buscando mejorar pero muchas veces estoy perdido.
Tanta publicidad y marketing cuando sale algo nuevo en programación no hacen mas que distraer la atención del objetivo de mejorar.

BigData, Tensoflow, IA, Augmented Reality, MicroServicios, serverless, graphql, Deep Learning, Blockchain, y un larguísimo etc. de términos y opciones que existen y que cuando surgen con la panacea de todos los problemas del mundo.

Al final estoy con mi ordenador, mi IDE, y mis lineas de código y lo veo pobre. Me da la sensación que todo el mundo ahí fuera esta en una ola de cambios y novedades que no llego a comprender.

Pero al final hay que mirar todo eso de cerca y preguntarse: ¿Realmente me sirve esto a mi o a mis clientes? Claro que muchas de las opciones son útiles pero en determinados casos de uso y otras están lejos de ser realmente realizables en proyectos comunes del día a día (al menos por ahora).

Sin embargo siento el agobio, la fuerte necesidad de saber qué son, cómo se usan, aprender las posibilidades (Aquí es donde mas marketing hay y  menos realidad), y sobre todo investigar el uso REAL de esa tecnología en particular.

Y resulta que muchas de ellas son irrealizables en proyectos pequeños, o incluso son una desventaja para un proyecto web determinado.

Así termino aprendiendo un montón de cosas que me llenan la cabeza de cosas fantásticas y cuando vuelvo a mi código, ese proyecto de mi cliente, me parece poco. Noto como me cuesta seguir con el código porque no es "ESO" tan fantástico que se usa ahora...

Ilusión. Eso es lo que es el marketing aplicado a estos términos. Si antes de Internet la ignorancia era un problema ahora lo es la saturación de información.

Si a veces te sientes abrumado por TODO lo maravilloso que hay ahí fuera y que no esta a tu alcance por falta de tiempo, tranquilo, hay mucho humo orientado a que las empresas inviertan para poder sacar adelante realmente la tecnología prometida.

No te dejes llevar por el marketing y no dejes de amar el código que escribes... (Eso es lo que me repito cada día como un mantra, espero que algún día funcione).

¿Opiniones?

Haz un análisis de sangre a tu software

Me gusta pensar que el software es un ser vivo que, tiene síntomas antes de enfermar, se puede curar, y por supuesto, tiene un ciclo de vida, nace, crece, se reproduce (copia y pega) y muere. Tampoco hace falta llegar al extremo de asegurar que tenga sentimientos pero un algoritmo de orden N siempre será más feliz que uno de orden N^2.

Siguiendo con la analogía con los seres vivos, necesitamos establecer qué podemos considerar que es la savia del software, la sangre, su fluido vital, y para mí son sin duda los logs de las aplicaciones. Si, sé que mucha gente los considerará más un fluido de desecho, del que también se saca información para curar al enfermo, pero sea de uno u otro modo, conviene hacerse un análisis de vez en cuando para controlar la salud general del software.

El software parte con una ventaja inmensa frente a los seres vivos, somos capaces de mantener su sangre analizada constantemente, pero otra cosa es que especialistas miren los análisis, y en eso acabamos por igualarnos. Imagina que pudieses tener monitorizado el contenido de tu sangre de forma constante, podrías saber de manera inmediata qué hábitos te provocan reacciones en tu salud, ¿acaso dejarías de pasar una oportunidad como esa para estar sano?. Seguramente no, por lo que deberías aplicar el mismo criterio a tus aplicaciones.

Si no tienes un sistema de correlación o agregación de logs, hazte con uno de inmediato. Hay multitud de ellos en el mercado y muchos de ellos de software libre:

• ELK: ElasticSearch, Logstash y Kibana es quizá el más conocido, quizá un poco más complejo para empezar pero muy potente cuando se acaba por dominar. (https://www.elastic.co/elk-stack)

• Graylog: Con componentes comunes con el anterior (ElasticSearch) pero que usa MongoDB y una interfaz gráfica más sencilla para empezar. (https://www.graylog.org/)

• Splunk: Una solución en la nube por si no quieres complicarte la vida montando infraestructura.  (https://www.splunk.com/)

Por supuesto que hay muchos más, pensados para todo tipo de software porque no es lo mismo analizar sangre de una aplicación web que de un router o un firewall donde buscas prevenir no tanto la salud del enfermo sino la dieta de lo que entra al sistema, y claro está, cuanto más enfocado esté el análisis mejor podrás diagnosticar al paciente o evitar que se infecte.

Este artículo no viene a darte una recomendación de cuál es el mejor para ti, dependerá de muchos factores, lo que si que trato es de animarte a que si no tienes ninguno de estos sistemas trates de ponerlo como prioridad, no te será tan complejo como pueda parecer, y que si lo tienes mires los resultados del análisis, aprenderás a sacarle partido. Para terminar de convencerte te contaré un par de casos con los que estoy seguro que te encontrarás la primera vez que empieces a utilizar este tipo de análisis sobre tu sistema, por muy buena salud que creas que tiene:

• Error esporádico: Antes de disponer de uno de estos sistemas es posible que hayas mirado los logs más de una vez, generalmente para resolver problemas y que te hayas encontrado con un error, que nada tenía que ver y que en el momento de crisis simplemente ignoras. Pues bien, llegará este implacable análisis para cuantificar este tipo de errores y hacerte ver que probablemente no era tan esporádico como creías e incluso que tiene un patrón y se debe a algo concreto, puede que poco importante, pero serás capaz de depurarlo. 

• Falso positivo: Este caso también es muy común, se trata de el típico mensaje de error que se emite para indicar que todo es correcto, bazinga !! Si, es cierto que en los entornos de producción los niveles de log son más restringidos por lo que en ocasiones en estos entornos sólo se deja constancia de los problemas en el log, y debes suponer que “no news good news”, pero a veces te ves tentado a dejar constancia explícita del éxito, pero claro cambiar el nivel de log puede provocar que se deje constancia de muchas más cosas que no te interesan. En ese momento el diablillo de la mala práctica te susurra al oído que emita tu mensaje de confirmación como un error para poder así verlo en producción, pero ahora en tu análisis te dirá que tienes un error, cuando en realidad no lo es. 

Se que ahora mismo piensas que Google Analytics te está ayudando en parte a hacer esto, y lo cierto es que, siguiendo con la analogía, podemos decir que es el amigo fiel que cada día al verte te dice si tienes buena cara o no, y te invita a visitar al doctor, pero difícilmente va a poder dar un diagnóstico del motivo por el cuál tienes tan mala cara. Una cosa a la que si te puede ayudar es Google Tag Manager, que te puede dar log de errores de los clientes. Tu aplicación falla en los clientes, los contagias a través de tu javascript, y en ese caso, puedes recopilar muestras de sangre de tus usuarios para diagnosticar la enfermedad que les estás contagiando y a la que tú eres inmune.

Sea como sea, una vez que empieces no podrás parar, la sangre que corre por las venas de tu software no va a parar de darte información sobre lo que pasa de forma constante, y querrás más. ¿Es posible saber la cantidad de errores 500, las peticiones POST, los logins por minuto,…? La respuesta es clara, podrás saber todo lo que quieras, basta con que hagas que fluya por la sangre de tu software.

Entre el arte y la ciencia: el comercio

Me encanta programar. Es una pasión que llevo en mi sangre desde que la descubrí. Lejos de ser una ciencia matemática y nada más lo veo más bien como una manera de hacer arte con una herramienta tan alejada de ello como es el mismo ordenador.

¿Porque hablo de todo esto? Porque a veces la pasión es un estorbo para vender un producto y estoy seguro de que a más de uno le pasa lo mismo.

Veo el mundo de hoy moverse a un ritmo trepidante donde todo es para ya. Esto que parece una enfermedad a veces es una necesidad por razones económicas. Proyectos que deben salir antes de una fecha, cumplir plazos, presentaciones en un evento, etc.

Pero sobre todo la rapidez es por un balance económico evidente. Sencillamente cuanto más tiempo lleva algo más caro lo debemos cobrar y por lo tanto más gasta nuestro cliente.

Yo he tenido proyectos que me permitían la creatividad, aprender cosas mientras realizaba el proceso, y además tenia casi casi libertad para elegir las herramientas para realizarlo.

Pero la mayoría de proyectos no lo permiten. No hay tiempo de hacerlo bonito ni perfecto. Hay que sacarlo rápido y funcional. No quiero decir con esto que se deba hacer mal, simplemente que a veces hay que dejar de lado esa pasión por hacerlo perfecto, único, inolvidable y simplemente hacer algo normalito...

Eso es fácil de decir y complicadillo de hacer la verdad. A mi me mata un poco el artista que tengo dentro (les recuerdo que no soy ni diseñador ni de frontend, simplemente la belleza del código de backend) pero hay que aceptarlo. Cuando el tiempo y el dinero están sobre la mesa hay que hacer lo necesario y poco mas. Los excesos tienen un costo de tiempo que el cliente luego no debería asumir porque fue nuestra decisión.

Pero ojo, JAMÁS deberíamos hacer porquerías... No es eso lo que quiero decir, sino que debemos aceptar que el índice de calidad de algunas cosas no debería ser tan excelente como quisiéramos porque el cliente no esta interesado en ello.

¿Cómo apagar ese fuego creativo si nuestros clientes no están a la altura? Creando cosas nuestras (sobre todo cosas útiles para nosotros), aprendiendo más cada día (mejoraremos en velocidad y calidad del código y podremos acercarnos más a nuestros ideas en los tiempos estipulados) y sobre todo escuchando lo que el cliente busca sin creer que nosotros sabemos más que el lo que necesita.

Seguramente esto equivocado... ¿Tú qué piensas de todo esto?

Tendencias en la programación actual

No sé si recuerdan cómo surgieron las metodologías ágiles. No se preocupen, este artículo no va de eso; simplemente recordemos que el concepto nace como contraposición a las metodologías como CMMI que anteponían la gestión de los requisitos al desarrollo del software.

Por situarnos: la metodología utilizada como contraejemplo era la metodología en cascada. Decían algo así como "La metodología en cascada es el demonio, nadie en su sano juicio debería utilizar la metodología en cascada", no exactamente así, pero entendéis la idea.

Recuerdo que en mi primer año de carrera, en la asignatura de Informática Básica, una de nuestras lecturas recomendadas era Managing the development of large Software systems del Dr Winston W. Royce publicado en 1.970.

En ese artículo, se define la metodología en cascada prácticamente en su segunda página con un gráfico que ha pasado a la posteridad:

Sé que esto ya lo sabíais, pero antes que saltéis directamente a otra página, permitidme que os muestre una copia del párrafo inmediatemente posterior a ese gráfico (las negritas son mías):

I believe in this concept, but the implementation described above is risky and invites failure . The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a l00 -percent overrun in schedule and /or costs.

Lo que dice a grandes rasgos es que la metodología en cascada, aunque es un concepto simple, es un proceso arriesgado y propenso a fallos y que puede llevar a un rediseño completo y por supuesto a sobrecostes si hay que rehacer el trabajo.

Casi al final del mismo artículo, curiosamente, presenta este gráfico:

que realmente presenta las bases de la metodología en espiral. Además, el mismo artículo habla de la importancia de las pruebas y le dedica un paso, el último, a explicar por qué se debe involucrar al cliente en el desarrollo. Una joya.

Por terminar con la presentación, recuerdo a mi profesor diciéndonos: "No se debería utilizar esta metodología, por supuesto hay métodos más eficientes, se explica porque es fácil de entender pero nadie debería aplicarlo, es como cuando explicamos los átomos con un gráfico similar al sistema solar. Sabemos que los átomos no son así pero es fácil de enseñar y comprender".

El caso es que lo aplicamos. Durante un montón de años. Teníamos todo un conjunto de protocolos asociados a la metodología en cascada o similar como Métrica. Así nos fué.

Si la persona que describe en primer lugar la metodología en cascada nos dice que no la utilicemos porque es peligrosa ¿por qué nos empeñamos en hacerlo? Muy simple: porque olvidamos nuestra historia.

Y esto nos lleva a las tendencias de programación actual, hemos pasado de la programación basada en estudio a la programación basada en foros y últimamente a la programación basada en gurús y modas.

Un ejemplo: llevo años enseñando a mis compañeros que el código no se debe repetir, que la programación de copiar y pegar no es buena, que dos, si hablamos de código, es un número excesivamente grande. Por una razón muy sencilla e histórica, el software es un modelo computable de un dominio de la realidad como decía Turing, si tenemos dos modelos, tenemos dos representaciones de la misma realidad.

Dicho de una forma más llana, si tu código se repite, cabe la posibilidad que si hay un error, corrijas sólo una parte y que el error perdure. Te costará tiempo y dinero corregirlo. La vida es dura, en resumen.

El caso, es que la tendencia actual va en contra de la filosofía de programación que considera anticuada y llegamos a un punto en que "si es necesario repetir el código lo repito porque la primera vez estoy en una fase de descubrimiento, la segunda la puedo entender como una fase de refinamiento y a la tercera he comprendido realmente la concepción holística del modelo y tengo un contexto mejor para refactorizar mi código y evitar las duplicidades" .

Puede parecerlo pero no estoy de broma, el discurso es más o menos así. Sé que no tiene nada que ver, pero ese tipo de argumento me recuerdan a lo que le decía Doña Jimena a Don Alfonso en la obra de teatro Anillos para una dama de Antonio Gala (años llevo queriendo meterlo en un artículo sobre desarrollo):

¡Déjame a mí de patrias! ¿No ves que estoy de vuelta de las grandes palabras? Las he mamado, Alfonso. Me he criado con ellas. He jugado con ellas, de niña, a la pelota... Apenas si he tenido marido, el que me diste, porque ya me lo diste con las grandes palabras. Y hubiera sido cariñoso y amante, Pero, ¡ah!, no pudo ser: allí estaban, en medio siempre de los dos, esas grandes palabras... ¿Y mi hijo? Mi hijo se quedó muerto, solo en mitad de un campo, con las grandes palabras por almohada... Estoy segura de que al morirse dijo «madre» y no «patria».

Me explico, no me hables de la concepción holística del software, me cansan las grandes palabras: dime que eres un vago, que no has pensado en el problema, que estabas escribiendo con el piloto automático y no te has dado cuenta, no me digas sin sonrojarte que lo has hecho intencionadamente. Estás dejando minas en tu código y te van a explotar en la cara. Pero sobre todo, no me pidas que lo haga. No compro.

Y eso nos lleva a cosas como la programación con componentes. Algo fundamental en el desarrollo desde el principio de los tiempos pero que últimamente llevamos al extremo. Antes de pensar cómo lo podríamos hacer vamos a buscar si en Internet hay algo parecido que puede servirnos. Y lo encontramos. No estamos muy seguros de si sus requisitos son exactamente los nuestros, si funcionará en nuestro sistema, pero ahí está. Hemos ahorrado un tiempo valioso en el desarrollo y vamos a utilizar posiblemente el cinco por ciento de un componente que no estamos seguros de si se va a mantener o no, que tendremos suerte si tiene algo de documentación y que habrá que tener cuidado que no cambie sus especificaciones, porque recordemos que es su código, no el nuestro.

Después nos extrañamos cuando once líneas de código JavaScript para hacer un left pad nos dejan sin Netflix y Spotify o cuando tenemos programadores a los que no les podemos pedir aplicaciones complejas porque tenemos buscadores de componentes no desarrolladores. Nos lo hemos buscado.

Porque eso sí, vamos a tener largas discusiones sobre el nombre que le ponemos a las variables y sobre la carga cognitiva del código (que sí, que se dice así) y vamos a utilizar sistemas molones de propagación de mensajes en lugar de llamadas simples a métodos (que ya no se lleva) que sabemos que consume más recursos pero la moda vende y sistemas de ORM que nos abstraigan de la base de datos aunque las consultas sean mas ineficientes y utilizaremos lenguajes de programación diseñados en quince días para hacer procesamiento en servidor porque en realidad no hemos aprendido nada.

¿Parezco enfadado? Disculpad. No lo estoy. Por si no os habíais dado cuenta este es un artículo en modo irónico, realmente me encanta hablar de los aspectos holísticos de la programación. Y de Dijkstra y de Turing y de Shannon, pero en fin esa es otra historia. No tan buena como Anillos para una dama, simplemente otra historia.

¿Dónde acaba mi proyecto?

Como programadores, las horas delante del PC picando código suelen ir encaminadas a un fin concreto y a un público más o menos definido: una aplicación web para gestionar un almacén; una nueva red social de amantes de las alcachofas; un sistema de recolección de logs para desarrolladores.

En algunos casos, nuestras habilidades como programadores serán suficientes para poner en marcha nuestro desarrollo. En el caso de programadores de aplicaciones móviles, el desarrollo acaba cuando se entrega un archivo empaquetado (apk para Android, ipa para iOS, vete tu a saber para Windows Phone). Para los que nos dedicamos casi en exclusiva al desarrollo de aplicaciones en web, la cosa es bastante distinta. No importa el lenguaje o el framework elegido, pues casi todo proyecto web debe ser alojado en algún lugar accesible por los usuarios de nuestra aplicación.

Como en todo, hay diversas situaciones y opiniones. Es probable que si trabajas en una gran empresa, cuando acabes con tu tarea de programador será otra persona la encargada del despliegue. En otros casos, la integración continua será la responsable de publicar tu trabajo, siendo tú o no el responsable de montar la arquitectura necesaria para que esto suceda. Y por último nos encontramos al conocido coloquialmente como Full Stack: un programador que una vez finalizado su proyecto web tiene que subirlo a un servidor y hacer que funcione.

Muchos administradores de sistemas en paro se quejan del auge de este nuevo perfil de programador capaz de acaparar el flujo completo de la creación y puesta en marcha de un producto. Está claro que en muchos casos se puede mear fuera de tiesto, pero el modo en el que programamos hoy en día ha propiciado que cualquier programador tenga que tener en cuenta el entorno mucho mas que antes: gestores de paquetes, librerías, sistemas gestores de bases de datos y un largo etcétera que hace años eran en muchos casos ajenos al programador que iba a su oficina a trabajar en el ordenador que alguien había configurado.

Los tiempos han cambiado y el programador se ha ido adaptando a él. Lejos quedan las peticiones a sistemas para que te permitiesen instalar una nueva aplicación que tenía que ser evaluado por miedo a virus. El programador de hoy en día se ha emancipado y si bien sus dotes de administración de sistemas pueden ser mas o menos limitadas, tiene mucho mas hígado que le capacita para tomar decisiones que antes le eran ajenas.

Y tu, ¿qué opinas?

¿Te ayudo? Enséñame como

Aquí vamos a tocar un poco las sensibilidades porque la experiencia que a veces tenemos la olvidamos con facilidad cuando progresamos en una profesión y también es verdad que a medida que avanzamos vemos cosas que antes no.

El tema: cuando alguien tiene la voluntad de ayudar pero no el conocimiento y el tiempo apremia.

Yo he sido un inútil, en muchas profesiones, la mía incluida. Siempre he tenido voluntad de ayudar pero a veces mi voluntad es lo que entorpece el trabajo.

Me explicare de forma sencilla.Yo hago FullStack por necesidad por en realidad soy de back. Y en front ahora mismo hay diferentes frameworks js y css. El problema de estos frameworks es la curva de aprendizaje frente al tiempo que luego nos ahorran en programación.

Es importante en este punto la especialización (o por lo menos así lo creo yo) por lo que uno profundiza en determinados frameworks y deja otros de lado. Y se avanza, lento o rápido, pero se avanza.

Ahora resulta que estas en medio de un proyecto usando un par de frameworks (js y css) desde hace un año, con un back (php) que poco a poco conoces aun más.

Pero en ese proyecto se suma una persona con conocimientos básicos de programación. Bien, genial. Mas gente sumada al proyecto. Ahora iremos mas ¿rápido? y aquí esta el problema.

Programar es una carrera contra reloj muchas veces donde el tiempo que le dedicas lo debes balancear entre aprender cosas nuevas (que te harán programar mejor), escribir código, resolver problemas (no todo es código) y eso que llaman "vida diaria".

Pues bien. Tenemos aquí a una persona con muy buena voluntad (si no fuera así la dejo en un rincón haciendo tareas rutinarias... De esas siempre hay) pero con el conocimiento justo o menos.

Sin buscar culpables porque no los hay, tenemos que buscar un tiempo para enseñar a esa persona el proyecto para que pueda ayudarnos a avanzar pero... ¿Vale la pena? Y aquí viene la herida de sensibilidades: A veces si, a veces no.

Porque todo el tiempo es inversión y como dice mi madre: "Mucho ayuda el que no estorba". Por lo que a veces debemos dejar a esa persona en "Stand By". Pero que lo hagamos no nos da derecho a mirarle por encima del hombro porque como dije al principio: a veces olvidamos que hemos estado en ese lugar que ahora le toca a otro. ¿Recuerdas? Ver todo el mundo sabiendo que hacer y uno como perdido,sin saber para donde tirar.

Paciencia a ambas partes y que los que saben no se sientan por encima y los que no saben que se pongan las pilas a aprender.

Y si no es en este proyecto, porque no se puede, nos vemos en el siguiente.... Vete preparando ¿no?

El técnico para todo

Programación:  Ese arte / ciencia que es tan difícil de explicar a veces de que se trata realmente a la gente que no esta relacionada con esta profesión.

Es que muchas veces nuestro trabajo no es "fácil de ver" sobre todo cuando se trata de resolver oscuros problemas en lugares recónditos del código.

Al final se crea un halo de intriga alrededor nuestro que hace que la gente que nos rodea a veces mistifique nuestra profesión.

Y pasamos a veces de "Se pasa todo el día sentado 'al ordenador'", dicho lo de 'al ordenador' con ciertas reticencias, a ser unos genios que entendemos cosas "super complejas".

Un día llega un familiar y te deja un móvil de aquellos antiguos que ya no hay para que le instales las aplicaciones mas modernas, o te dicen que mañana te pases por tal sitio a mirar un motor de nevera que no funciona o te dejan algún electrodoméstico medio destruido para que lo arregles "porque tú sabes de estas cosas"

Es extraño que cuando viene el técnico del cable nadie le pida que también mire los cables del router a ver si están bien conectados pero nosotros pasamos a ser técnicos para todo.

Y a veces fomentamos la vagancia y dependencia. Porque sí. Porque nos gusta ser útiles y que nos necesiten.
"¿Me configuras esto del móvil?" "¿Me limpias el pc?" "Es que no sé leer los correos"...

El problema de eso es cuando se dispara la voz. Uno le ayuda a un amigo y/o familiar, este le dice a otro, el vecino nos pregunta si sabemos y así en poquito tiempo tenemos "fans" de nuestra genialidad (porque siempre está el "porque tú sabes") que de petición en petición nos consumen el tiempo y la energía.

Y como decir que no sin ser borde. Es complicado. Yo por lo pronto explico todo lo que hago para otros, lo deshago y le pido a la persona que lo rehaga (todo esto cuando es posible) estoy el doble de tiempo con esa persona pero pueden pasar dos cosas:
* Aprende a hacerlo (Lo cual es bueno para los dos)
* No me vuelve a consultar porque "le hago hacer el trabajo"

Lo cierto es que ni aun así (y créanme cuando dijo que se ser muy borde cuando hace falta) logro hacer entender a la gente que me rodea en el día a día que no sé (y la verdad no me interesa saberlo) entrar a cuentas de facebook sin contraseñas, crear una app de moda en un fin de semana o crear la nueva red social del futuro pero que sigo siendo bueno en mi trabajo.

Me pregunto si en muchas profesiones pasan por lo mismo.

Un área TIC ágil en la administración pública (parte I)

Nunca es fácil meterse a hacer cambios dentro de una administración, pero es mucho peor intentar cambiar cosas que ningún órgano de dirección te haya pedido. Esto suele darse cuando quieres hacer cambios para  beneficiar (según tu criterio) en la manera como se realiza el trabajo.

No quiero generalizar cuando hablo de la administración. Hay muchas, de varios tipos y con gente muy diferente. Simplemente hablo desde la pequeña ventana que tengo hacia este mundo.

En mi caso, ya hace bastante tiempo que estoy convencido que aprovechar lecciones que nos dan metodologías, filosofías y tendencias en las TIC beneficiaría el modo en que ofreceremos los servicios. No creo que tengamos que volvernos unos fanáticos, pero sí que es necesario hacer cambios en la forma de pensar las cosas para dar la vuelta a ciertas situaciones, que sin querer, nos dejan atados de manos y pies.

En muchos aspectos, la administración es un buen lugar para aplicar metodologías adaptativas y en muchos casos la única forma viable para los proyectos. En mi caso llevo tiempo experimentando en el uso de metodologías ágiles y la filosofía de DevOps. Lo hago desde un puesto en el que no me es posible aplicarlo transversalmente a todo el área TIC, pero poco a poco he podido convencer a algunos compañeros y compañeras de diferentes divisiones (secciones) que adquieran estas prácticas. Eso aunque puede sonar bien, no nos deja en una situación demasiado cómoda para nadie.

En mi sección tenemos varias responsabilidades. Somos (teóricamente) el equipo de desarrollo, pero en un área TIC estructurada totalmente funcional. Con lo cual nos quedamos con la gestión de todo aquello que ponemos en marcha. Ya llevamos bastantes años trabajando y si queríamos seguir desarrollando la mayoría del tiempo, teníamos que abrazar filosofías que nos permitiese reducir al máximo el trabajo no planeado, repetitivo que no aportase valor.

En este momento, en nuestra sección gestionamos los proyectos relativamente grandes usando Scrum, y del resto intentamos gestionarlo mediante Kanban, sobretodo lo referente a incidencias y gestión del cambio. Tenemos incorporada la filosofía del testeo automatizado, documentar aquello relevante, compartir la información del trabajo que se esta realizando, CI/CD, checkings de seguridad automatizados, monitorización, etc. Con todo esto y con algunas técnicas más tenemos mayor capacidad para desarrollar nuevos proyectos. Pero este mismo salvavidas que nos permite flotar es también el que nos deja ahí tirados en medio del mar, ya que hemos optimizado una pequeña parte del servicio pero no se ha extendido al resto del área.

Esta forma de trabajar nos ha funcionado por la forma que tiene de distribuirse el área. La parte de operaciones se encarga del mantenimiento de la infraestructura (hw, virtualización, red y backup), pero no va más allà, ya que ellos también se hacen responsables de punta a punta de otros servicios TIC. Una vez nos han dado los recursos solicitados para desplegar el proyecto va de la mano de nuestro equipo mantener los servidores actualizados, seguros, monitorear cargas, gestionar BDs, establecer protocolos de recuperación, etc. Pasa lo mismo con el soporte al usuario de los servicios. Podemos decir que damos el soporte de nivel 2 del servicio (al que van incidencias desde nivel 1 con mucha facilidad), con lo cual nuestra mayor preocupación al poner en marcha los servicios es hacerlo de tal manera que lleguen las menos posibles. Aunque parezca obvio que esto debe ser así, no todo el mundo lo hace.

Trabajar así tiene sus ventajas e inconvenientes. Por ejemplo nos permite tener mucho feedback, tenemos más cerca al cliente, y tenemos en mente toda la cadena de valor, pero eso es porque casi toda pasa por nuestras manos. Para dar un servicio de calidad va muy bien, pero si vas a tener varios servicios gestionados de esta manera se va a saturar. Si no se controla se cae en ese trabajo que no queremos. Normalmente se empieza por distanciar más las actualizaciones de servicios, y a partir de ahí se entra en una espiral de trabajo no planeado, tareas más costosas, etc. Es muy fácil caer allí y muy difícil salir.

Ampliar el número de personas que hay en una sección (funcional) ayudaría, pero tampoco es el maná. Llegará un punto en que se tendrá divisiones completamente aisladas dentro del área TIC, donde no se aprovechan recursos que podrían ser fácilmente compartidos, donde la información quedará aislada, y los flujos de comunicación con otras divisiones debido a las dependencias (malditas dependencias) se resentirá. Además, es mucho más difícil y lenta la justificación de la necesidad de más personas en una sección en la que se tiene tareas de todo tipo sin que queden muy claros los perfiles, que si tenemos claros los puestos de trabajo que intervienen en la cadena de valor de los servicios, y está clara qué capacidad de trabajo y el nivel de ocupación tienen.

En el siguiente post explicaré cuáles son las reticencias que se presentan cuando se plantea extender las metodologías y filosofías de forma global al área TIC (y a la institución).

Declaración de intenciones

Cuando empiezas en el mundo de la programación, pueden suceder muchas cosas distintas que dependerán de tu entorno. País, estudios, sexo, clase social... Pero hay cosas por la que todos hemos pasado en un momento u otro de nuestra vida como desarrollador/a.

Una tarea que no tiene sentido; un cliente que pide algo que parece imposible; una aplicación que no compila. Nos enfrentamos a situaciones únicas cada día de nuestras vidas y las manejamos como buenamente podemos. La primera opción suele ser buscar en el alma mater compartido a través del planeta: Stack Overflow. Por algún motivo (que desgracia) nadie ha tenido el mismo problema, o bien nadie a podido encontrar una solución. Pero tu, programador de mierda, no cejas en tu empeño y exprimes tu cerebro al máximo. Lo haces, encuentras una solución. ¿Qué haces entonces?

Tienes varias opciones, como buscar preguntas sin respuestas y contestarlas. También puedes crear una pregunta en Stack Overflow y contestarte a ti mismo/a. Suena absurdo pero no es una práctica nueva. Una opción factible es crear un repositorio en Github y compartir tu código. Al principio te sientes expuesto, pero con el tiempo no dudas en subir hasta la lista de la compra. Otra opción (la mas usada) es hacer la ñapa y olvidar el tema lo antes posible. Que pereza compartir algo que posiblemente no vuelva a pasarle a nadie.

Desde la comunidad de Programar es una mierda proponemos una nueva vía. Cuenta tu historia al mundo. Por absurda que parezca, por bizarra que se antoje, es casi seguro que dentro de 2 días o de 3 años volverá a pasarle a alguien. Estoy seguro que tienes algo que compartir: un proyecto donde el cliente solicitó features ridículas; una tarde perdida porque el compilador no tenía permisos de escritura tras actualizar el IDE; un servidor que se caía cada 5 minutos al consumir una url concreta.

Muchas de estas historias que pueden ser simples anécdotas en nuestra vida laboral, pueden ser de utilidad para otros miembros de la comunidad. Queremos darle un altavoz a esa gente que quiera contar esas historias del día a día y hacerlas visibles ante otros miembros de la comunidad.

Y tu, programador/a de mierda, ¿tienes algo que contarnos?