Autor: Iñigo Serrano

En la entrada anterior hable sobre lo que es memcached y como su uso puede ayudarnos a agilizar una aplicación guardando datos en memoria.

Esto suena de maravilla, pero siempre hay un reverso tenebroso que quiero contar en esta entrada. Es una entrada sobre un concepto fundamental: CRITERIO

Me explico, si empezamos a almacenar datos y más datos en memcached para que vaya todo más rápido nos encontraremos que o tenemos una cantidad ingente de memoria RAM disponible o va a llegar un momento que memcached va a llegar al límite que hemos fijado y va a proceder a descartar.

Toda la gracia del memcached es cachear una información que es costosa de conseguir para que la siguiente vez que se necesite no tener que volver a pagar el precio de conseguirla. Pero si hemos saturado la memoria y el memcached ha tenido que eliminar contenido, nos saldrá más caro, porque tendremos que ir a la caché, ver que no está (que consume tiempo) e ir a la fuente original.

Hay que cachear con CRITERIO.

Tengo últimamente un poco abandonado el tema de la arquitectura de aplicaciones web, básicamente porque últimamente se han dado situaciones que me han hecho plantearme o recordar cosas más relacionadas con el otro gran tema del que suelo hablar, que es la industrialización.

Pero hoy me ha llegado un email de mi proveedor de hosting, bueno ahora es más cool llamarlo nube, y tenia una entrada en su blog sobre memcached.

Para los que no tengan muy claro que es memcached, aparte de leer el citado blog, decir que es un software que almacena en memoria datos. Podríais pensar que eso no es nada nuevo, una simple tabla hash de java almacena datos en memoria.

Y en esencia es lo mismo, pero memcached es una hash vitaminada, muy vitaminada.

Las ventajas que nos aporta son las siguientes:

– Se puede poner un límite al empleo de memoria, es decir si en una hash de java metemos datos sin parar nos quedaríamos sin memoria. En memcached en cambio cuando llega al límite marcado empieza a descartar.

– Se puede poner un límite de tiempo, es decir a diferencia de la tabla hash de java en la que una vez metido un valor nosotros tenemos que borrarlo manualmente o ahí se queda de por vida, en memcached podemos decirle el tiempo que queremos que se mantenga y el solito lo borra una vez pasado ese tiempo.

– Se puede compartir y esta es una de las principales diferencias con una hash de java. La hash de java vive en la memoria de la máquina virtual, así que el acceso es muy rápido pero solo puede acceder a ella el código que se ejecute en esa máquina virtual.

Si tienes por ejemplo una aplicación de ventas de libros con varios servidores y decides cachear todos los productos, cada servidor tendrá una copia del catálogo de productos.

Es decir un acceso muy rápido pero poco eficiente en el uso de los recursos.

Memcached en cambio es un servidor. Eso quiere decir que es un poco más lento, pero aprovecha mejor la memoria.

Estaba esta tarde mirando un reloj que tengo mecánico y automático. Es decir de los que hay que darle cuerda o llevarlo en la muñeca para moverlo y se de cuerda el solo. De esos que el segundero camina seguido no a saltitos como los de pila.

Son relojes que adelantan o atrasan un montón y hay que preocuparse de darlos cuerda o ponerlo en hora, pero me encanta ponérmelo de vez en cuando y escuchar el tic-tac. Sin nada de electrónica ni electricidad, es una cura de desintoxicación.

En el mundo de los relojes lo tienen muy claro. La funcionalidad principal de un reloj es dar la hora y lo demás son complicaciones. Y así se refieren a ellas, sin medias tintas ni nombres rimbombantes… com-pli-ca-cio-nes.

Pero claro tienen una ventaja sobre los informáticos. Relojes se llevan haciendo desde hace mucho antes que programas de ordenador y nos llevan mucha ventaja.

Hoy día se empieza a extender el concepto de KISS, que ya he tratado en alguna entrada. También ciertos principios o filosofías como el Lean de fabricación esbelta, que aboga por eliminar los desperdicios.

Antes de ayer terminé el curso sobre agilismo que impartía Javier Garzás.

Me ha resultado muy interesante, ya que me ha permitido asentar algunos conceptos y entender la motivación de algunas cosas que conocía del agilismo.

Desgraciadamente en los entornos en los que me he movido profesionalmente se estila más el ciclo de vida clásico. Mucho por inercia, y mayormente por la imposición del modelo de contratación de los trabajos.

Pero poco a poco si que se ve que se va introduciendo el agilismo, o por lo menos ciertas prácticas ágiles.

No creo que el agilismo sea para todos los proyectos, ni el ciclo de vida en cascada lo es, pero si creo que en determinados tipos de proyectos es útil.

También reconforta el ver que ciertas prácticas que has ido empleando de manera más o menos intuitiva están recogidas y se fundamentan con estudios más académicos que la pura intuición o lógica personal.

Me viene a la memoria una imagen de una responsable de proyecto de un cliente que ante la duda de como tenia que funcionar un aplicativo nuevo que estaba substituyendo a otro viejo, en vez de consultar la documentación, y era un sitio muy burocrático en ese tema, prefirió investigar el código fuente del programa viejo, simplemente porque no se fiaba de la documentación.

La industrialización del software está muy ligada con la metodología que se emplee y creo que es muy interesante para las personas que estén en entornos de ciclo de vida en cascada empaparse un poco de otras formas de organizar el trabajo.

En una ocasión me encargaron un proyecto, no muy grande. Era un equipo de dos programadores más el jefe, pero como este no tenia conocimientos de tecnología Java entre yo como especialista.

Así que monté el proyecto con una visión más a largo plazo de lo que se suele hacer.

Sabía que íbamos a tener que entregar el diagrama lógico y físico de la base de datos, así que en vez de hacer las modificaciones de las tablas directamente en la base de datos y al final del proyecto documentar utilizamos una herramienta de modelado de datos para hacer los cambios, generar el script y rehacer la base de datos con ese script. Cuando tuvimos que hacer la instalación en el cliente ya teníamos el script hecho y perfectamente validado. Cuando tuvimos que entregar la documentación de la base de datos, también ya la teníamos y perfectamente actualizada.

Para la gestión de las tareas en vez del típico excel o emails utilizamos un gestor de tickets, que nos permitió tener muy controlado todo el trabajo que se iba realizando y el pendiente de realizar.

La lección que sacamos de esa experiencia es que si dedicas un poco de tiempo al principio del proyecto a construir unos pilares sólidos al final del proyecto te dan sus beneficios. El proyecto no se desvió por esos motivos, si por otros.

Fueron medidas sencillas de aplicar con un muy buen resultado. El problema es que a veces la gente se obsesiona con el «si hacemos esto mejoraríamos a largo plazo» y acaba cayendo en la sobreingeniería. Que es tan mala o incluso peor que el hacer las cosas chapuceramente.

Últimamente se oye hablar mucho sobre la industrialización del software, como algo no siempre adecuado, y muy asociado al ciclo de vida en cascada o waterfall.

No tengo muy claro si el termino de industrialización en el campo del desarrollo de software está muy claro. En alguna ocasión he expuesto mi punto de vista.

Si por industrialización entendemos la cadena de montaje de un coche si puede asimilarse al ciclo de vida en cascada.

Si por industrialización entendemos el tener definido un método de trabajo adecuado a la empresa y proyecto en el que estamos desarrollando el trabajo, con sus correspondientes procedimientos, etc. No creo que sea necesariamente asimilable al ciclo de vida en cascada.

Es decir una empresa o proyecto puede tener metodologías y procedimientos perfectamente ágiles.

Lo que no creo que sea asumible son los proyectos o empresas en las que, por ejemplo, se ha perdido código por no tener un control de versiones riguroso.

Creo que en el planteamiento del agilismo, como por ejemplo en Scrum, hay una trampa. Cuando se habla de equipos autoorganizados, se pone una precondición muy importante y que aveces se nos olvida, que es la de conseguir gente con talento. Pero no siempre es posible tener ese tipo de personas.

Por eso me parece importante, tanto en agilismo como en el ciclo de vida en cascada el definir la metodología y los procedimientos, ágiles o no, y que se cumplan a rajatabla. Y si hay que adaptarlos se adaptan.

En mi opinión lo ideal sería que se definiesen a nivel de empresa, para que si se tiene que mover una persona de un proyecto a otro el tiempo invertido en ponerse al día sea mínimo. Al final nuestros clientes lo que quieren es un producto Bueno, Bonito y Barato.

Todos estos tipos de condicionantes hacen que no se pueda aplicar una metodología ni ágil ni no ágil sin una adaptación, labor que se debe hacer por los ingenieros de software.

Desde mi punto de vista la industrialización del desarrollo de software debe propiciar una serie de beneficios a la empresa o proyecto.

– Aumento del control sobre el proceso productivo y reducción de la producción artesanal.

La producción artesanal entendida como el programador que está en su sitio haciendo las cosas en principio perfectamente, pero a su aire. Llegado el momento que por ejemplo se pone malo y sea una odisea que alguien retome su trabajo.

Suelo aplicar un decálogo que me funciona muy bien.

– Reducción de los tiempos dedicados a tareas que no aportan valor al cliente.

A los clientes les importa cero nuestras elucubraciones mentales de metodologías, herramientas, polimorfismos, complejidades ciclomáticas y demás parafernalia. Lo que quieren es un producto Bueno, Bonito y Barato.

Unos compañeros que llevaban una parte del proyecto me comentaban que una de las cosas que más valoraban los usuarios, médicos en este caso, era que a la hora de pedir una radiografía para un paciente, les aparecía un dibujo de una persona y si querían una radiografía del brazo, pinchaban en el brazo en vez de en un desplegable… Estas cosas como técnicos nos debieran de hacer reflexionar.

– Aumento de la homogeneización de los productos elaborados.

Sobre este punto ya he comentado en alguna ocasión con un ejemplo práctico de como encarecer el producto sin aportar valor al cliente.

– Creación o mejora de los procedimientos técnicos para las auditorias externas (CMMI, ISO,…)

Estudié en un colegio de «curas» y una vez uno nos dijo que «En esta vida además de ser santo hay que parecerlo«. Que un auditor externo te ponga un sello significa que por lo menos tienes cierta preocupación por la calidad y que cumples unos mínimos.

– Reducir el malestar entre los involucrados en el proyecto debido al sobre esfuerzo que se debe realizar para compensar las ineficiencias.

Siempre que pienso en la industrialización del desarrollo de software me viene a la cabeza la imagen de la maquinaría de un reloj. Si la maquinaria no está bien ajustada y engrasada hay que aplicar mucha más energía para moverla. Y eso cansa y sobre todo desespera. Y este es un sector en el que lo principal son las personas.

Decía Kent Beck en su libro de programación extrema que si sales de casa para ir al trabajo y tienes un nudo en el estómago es mala señal. Hay que ir con cierta alegría y volver a casa cansado pero satisfecho.