domingo, 25 de junio de 2017

Lo pequeño es hermoso


Lo pequeño es hermoso” es el título de un libro publicado en 1973 por F Schumacher. Su nombre completo es “Lo pequeño es hermoso: Economía como si la gente importara” y defiende el uso adecuado de los recursos, procurando utilizar opciones sencillas y recursos lo más limitados posibles.
Este criterio, que siempre ha sido válido, se hace cada vez más necesario en el mundo de la tecnología. Parafraseando el título, podría decirse “Lo pequeño es hermoso: TECNOLOGÍA como si la gente importara”.
Si observamos la tecnología que utilizamos habitualmente, veremos que las páginas Web aumentan cada año su tamaño (peso) medio ( http://httparchive.org/index.php ), de forma que aunque las comunicaciones han mejorado mucho y el ancho de banda disponible para descargar una página se ha multiplicado por 1000 en 20 años, el tiempo de espera en algunos casos es el mismo que cuando se utilizaba un modem a 33k.
Algo equivalente puede decirse de las aplicaciones. La mayoría de los móviles actuales, y desde luego cualquier ordenador, tiene mucha más potencia, memoria y velocidad que ordenadores de hace 20 o 30 años (recordemos que una memoria RAM de 4 megas y un disco de 200 Megas eran “un buen equipo”, por no hablar del PC inicial, con 640K y un disco de 10M). Sin embargo, muchas aplicaciones que utilizamos no parece que vayan mucho más rápidas que hace años, e incluso algunas van más lentas claramente. Además, muchas tienen unos tamaños “monstruosos” para lo (poco) que hacen.
En algunos casos se puede decir que las aplicaciones modernas “hacen más” (se revisa la ortografía y gramática en tiempo real, se presentan gráficos de diverso tipo, se ubica la posición y se hacen cálculos en base a la misma, etc.) pero no tanto para justificar esos rendimientos.
Creo que hay varios motivos que podemos agrupar en personales y tecnológicos:

Personales:
Uno importante sería la despreocupación de algunos desarrolladores (“ahora los equipos son rápidos”, “hay memoria suficiente”, “Todo el mundo tiene mucho ancho de banda”), que provoca que no se intente optimizar el código, ahorrar memoria o ahorrar ancho de banda. 
A ello se une la falta de programadores con experiencia, que es otro factor importante. Programadores veteranos que han aprendido trabajando con ordenadores y herramientas con pocos recursos se han acostumbrado a optimizar y ser ahorradores y tienden a diseñar los programas de forma “austera”.  
Si a eso se añade la necesidad de cumplir los plazos y las especificaciones, no de cumplirlas “óptimamente”, se comprende que en muchos casos la eficiencia queda en último lugar.

Tecnológicos:
Muchos de los lenguajes de programación se “encargan de gestionar la memoria” (como ocurre con java) un desarrollador, aunque sepa con total seguridad que ya no necesita un elemento, no puede borrarlo y debe esperar a que “se borre cuando se pueda”. No bastante creo que el principal motivo son la “herramientas de ayuda al desarrollo”, entre las que podríamos incluir el uso de diversas librerías, framework de desarrollo y herramientas para generación de código. Dado que los lenguajes y herramientas de programación no incluyen todas las funciones posibles para todas las necesidades, se suele acudir a librerías de funciones que contiene diversas funciones (manejo de sonido, imágenes, cálculo, gráficos, etc.) que permiten realizar operaciones sin tener que desarrollar desde cero ese código. El problema es que en muchos casos, el utilizar unas pocas funciones implica arrastrar toda la librería de funciones completa. Es decir, necesitamos, por ejemplo convertir una imagen de formato, o recortarla, pero las librerías incluyen funciones para todos los formatos, para girar, recortar, alterar el color, etc.
Con los framework de desarrollo, que a diferencia de las librerías no ofrecen conjuntos de funciones sino esqueletos de desarrollo sobre los que se encaja nuestro proyecto, pasa algo similar. Están planteados para un modelo de trabajo con una serie de relaciones y comportamientos, de los cuales es posible que muchos elementos sobren para el programa que se desea desarrollar. De nuevo se arrastra una enorme estructura y cimientos planteados para un edificio de 5 plantas cuando lo que se desea una casa unifamiliar (o quizá una casa de 5 plantas pero con otra distribución).
Por último, hay muchas herramientas que para facilitar la vida, permiten generar código fuente. pero ese generación, aunque cómoda, al ser genérica no siempre suele ser demasiado eficaz, con lo que se gana en velocidad de desarrollo (y en ocasiones en calidad y normalización) no se gana (o se pierde) en eficiencia.
El resultado es que con bastante frecuencia tenemos una gran cantidad de programas de dimensiones desmesuradas, peleando por los recursos y consumiéndolos inútilmente. Al igual que ocurre con la contaminación, la emisión de un coche no es demasiado significativa, la de miles, sí. Y todos sufrimos ese exceso de consumo de recursos sufriendo programas lentos y enormes. La memoria, o el ancho de banda de comunicaciones, al igual que los recursos naturales, no son infinitos y es mejor usarlos razonablemente.
Los anglosajones utilizan la expresión “Keep It Simple, Stupid” (K.I.S.S.: "Mantenlo simple, estúpido") también expresada como : “Keep It Short and Simple” ("Mantenlo corto y simple") o “Keep It Simple and Safe” ("Mantenlo simple y seguro") que puede considerarse una especie de Navaja de Occam,  pero aplicada, no al análisis o interpretación, sino al diseño y construcción.

Ejemplos prácticos:
Habrá quien piense que esto es algo teórico y que un programa “serio” necesariamente es grande y complejo. Para demostrar que es posible voy a citar algunos ejemplos:
  • Base de datos: HSQLDB es un gestor de base de datos Open Source que además de cumplir todos los requerimientos de una BBDD relacional y ser extremadamente rápida (http://www.h2database.com/html/performance.html), incluye las siguientes funciones:
    • java puro que funciona en cualquier sistema operativo
    • Emula funciones y sintaxis de otras bases de datos
    • Puede trabajar como base de datos en memoria
    • Puede configurarse para trabajar de modo portable
    • Un fichero jar de 1,5 M incluye el servidor de BBDD, el cliente JDBC y un interfaz de usuario gráfico. 
  • Servidores de aplicaciones: Jetty es un servidor de aplicaciones Open Source similar a Tomcat que cumple todas las funciones necesarias como cualuier otro (https://en.wikipedia.org/wiki/Comparison_of_web_server_software) (quizá solo se echa en falta un interfaz de administración avanzado) y que ocupa unos 11M completo (aunque puede embeberse y utilizarse solo el núcleo del servidor empleando prácticamente un tercio).
  • Motor de indexación por texto completo: El proyecto Open Source Lucene es el motor de indexación y búsqueda por texto completo más utilizado en el mundo, tanto directamente como a través de recubrimientos como Solr o ElasticSearch. Su núcleo, que permite indexar y buscar, ocupa solo 5M.
  • Gestor Documental: OpenProdoc es un gestor documental Open Source completo que incluye todas las funciones de cualquier gestor documental, junto con un gestor de tesauros. Dispone de una versión portable, que gracias al uso de las tres herramientas antes citadas, así como a seguir el principio KISS, ocupa 80M completo, lo que para un gestor documental, teniendo en cuenta que incluye servidor de BBDD, servidor de aplicaciones más el propio Gestor, es poco comparado con algunos clientes de gestor documental que ocupan 700M, o instalaciones de servidor de 1G
  • Utilidades Android: El programa Army Knife, contiene en 2,3M las siguientes herramientas:
    • Calculadora científica
    • Linterna
    • Conversor de unidades,
    • Temporizador/cuenta atrás
    • Cronómetro multi-vueltas
    • Brújula
    • Nivel
    • Lupa
    • Espejo
    • Regla (cm/pulgadas)
  • Gestión de imágenes: El programa Irfanview en solo 2M incluye visualización de prácticamente todos los formatos de imágenes existentes, conversión de formatos, manipulación completa de imágenes (profundidad de color, resolución, filtros, etc.), procesos de conversión en lotes, creación de miniaturas, etc.

Colibrí Mdf [GFDL (http://www.gnu.org/copyleft/fdl.html) CC-BY-SA-3.0


La conclusión es que “sí se puede”, por tanto creo que es importante que como usuarios o como desarrolladores o diseñadores sigamos el principio de : “Lo pequeño es hermoso: TECNOLOGÍA como si la gente importara” a la hora de crear herramientas o de utilizarlas. El "medio ambiente tecnológico" y nuestro paciencia o nervios lo agradecerán.

sábado, 10 de junio de 2017

El altísimo coste del “ahorro” en ordenadores y equipamiento.

Hace años, en un proyecto de gestión documental que estuve desarrollando para un cliente, se instaló el servidor en mi portátil, de forma que las 5 personas del equipo que yo dirigía se conectaban al mismo, desarrollaban y probaban contra él. Exactamente dos días DESPUÉS de acabar el proyecto se quemó el cargador de mi portátil. Cuando fui a la sede de la empresa en que trabajaba para solicitar un cambio, recogieron el antiguo y me indicaron que “ya me avisarían”, pues la norma era no tener recambios. Tres días después, en los que no puede prácticamente trabajar, revisar correo, etc. pude ir a recoger el cargador.
By Evan-Amos (Own work) [Public domain], via Wikimedia Commons

Haciendo una pequeña evaluación del impacto económico:
  • Coste de una fuente de alimentación media: 20€
  • Coste aproximado perdido por 3 días (asumiendo un salario medio bruto + costes empresa SS,..): (44.000 €/220 días trabajo)*3 días = 600€ por tres días de una persona
  • Si la avería se hubiera producido una semana antes: 600€* 6 personas =3.600€
La conclusión de la historia es que por no tener inmovilizados, no ya gastados (salvo que nunca se rompa ningún cargador de ningún empleado) 20€, se perdieron 600€ y se podían haber perdido 3.600€.
Las cifras pueden parecer exageradas pero no lo son en absoluto, y eso solo contando “costes”. Si esas personas estuvieran en una asistencia técnica como consultores, facturando al cliente, por ejemplo 50€/hora, hablaríamos de:
  • 50€*8h/día*3 días*6 personas = 7.200€ que no podrían facturarse (o podría hacerse “engañando” al cliente)
Tampoco se incluye “costes de oportunidad”, cumplimiento de plazos, posibles penalizaciones, impacto en otros equipos, etc.
Por un clavo se perdió una herradura, por una herradura se perdió un caballo, por un caballo se perdió una batalla, por una batalla se perdió un reino”
Puede alegarse que sin equipo se puede trabajar “en otras cosas”, pero en gran parte de las empresas actualmente, sin ordenador puede hacerse pocas cosas. El correo está en el ordenador, las herramientas de trabajo están en el ordenador, la documentación está en el ordenador, ….
Lo lamentable es que esto no es una anécdota, es un mal muy extendido.
Un extraño sentido de “ahorro” provoca que en muchas empresas de tecnología (y de muchos otros tipos) no haya habitualmente recambios, ordenadores de repuesto o que, desde que se incorpora un empleado a la empresa hasta que se le suministra el ordenador pueda pasar 1 semana (o hasta dos semanas).
Dado que en la mayoría de las empresas las compras de equipos suelen estar normalizadas y se compra una cierta cantidad de ordenadores de la misma marca y modelo, parece razonable pedir una serie de cargadores adicionales, válidos para todos (o casi) todos los equipos, de forma que, ante cualquier avería, en menos de un minuto se remplace el elemento averiado si perder ni un minuto. Según la calidad estimada de los equipos comprados, quizá un cargador adicional por cada 10 o 20 equipos. En el peor de los casos, suponiendo que nunca se estropee ninguno, se habrá gastado un poco de dinero, en el mejor, se habrá ahorrado miles de euros a la empresa.
Pero aún se puede ir “más lejos” en cuanto a evitar pérdidas de tiempo con una pequeña inversión. A raíz del incidente que citaba inicialmente, recuerdo que un compañero me comentó que en su empresa anterior, se entregaban AUTOMÁTICAMENTE, con cada portátil, DOS cargadores. De forma que uno se dejara fijo en la oficina y otro estuviera siempre en el maletín del portátil. Esto ahorra:
  • el estar colocando y recogiendo el cargador cada vez que se llega a la oficina,
  • el riesgo de olvidar el cargador y solo poder trabajar 2 horas fuera (en cliente, reuniones,   guardias o incidencias),
  • por supuesto las posibles averías del cargador, etc.
Simplemente 1 minuto diario de ahorro para conectar el cargador implicaría 220 minutos/año lo que amortiza sobradamente los 20€, sin contar el resto de factores, que no son en absoluto desdeñables.
Esto ocurre con un elemento aparentemente menor y trivial. Si pensamos en el ordenador de trabajo, el efecto es mucho mayor. Suele darse dos “ahorros” habituales:
  1. No tener equipos disponibles de reserva, tanto para las nuevas incorporaciones como para posible averías
  2. Tener equipos poco potentes.
En cuanto a no tener equipos de reserva ya preparados e instalados con las aplicaciones licenciadas y habituales de la empresa, tanto para entregarlos a los nuevos empleados como para dar un equipo temporal de sustitución, es un mal muy extendido. Conozco empresas donde se tarda en entregar el nuevo equipo una semana y hasta un mes. De nuevo aplicando los cálculos anteriores, contando con 200€/día * 5 días, se pierden 1.000€ /semana y 4.000€/mes. De nuevo sin contar otros costes como impacto en otras personas, retrasos, mala imagen, descontento del empleado,... Estas pérdidas aplicarían tanto a los casos en que no se tiene un equipo preparado para los nuevos empleados como los casos de averías.
Respecto al ahorro en la compra de los equipos, tiende a comprarse equipos “económicos“ para todos los empleados, y, aunque esto puede ser válido para los que solo realizan tareas ofimáticas, no lo es para una gran parte de las tareas habituales hoy en día, desarrollo, diseño, edición, calculo, administración, etc. Por ejemplo programando aplicaciones es necesario compilar con mucha frecuencia, instalar servidores de aplicaciones o de bases de datos en el ordenador personal, arrancar un simulador de móvil, etc. Son tareas que llevan mucho tiempo, requieren ordenadores potentes y que en muchos casos obligan al usuario a esperar en diversas tareas (compilación, despliegue, realizar pruebas automáticas, etc.)
Un equipo que permita trabajar un 1% más rápido (algo no muy difícil: CPU Benchmark, Disco duro vs Disco de estado solido) implica ganar/ahorrar 2 días/año, es decir 400€. Con una amortización de 3 años implica 1.200€. Es decir una ganancia de solo un 1% justificaría gastar 1.200€ mas, y desde luego esa no es la diferencia de precio entre equipos con un 1% más de potencia.
Por shigeru23 [GFDL (http://www.gnu.org/copyleft/fdl.html) undefined CC BY-SA 3.0

Dado que el ahorro que se consigue invirtiendo un poco en recambios y equipos más potentes parece evidente, ¿Por qué no es la norma? (al menos según mi experiencia y la de muchas personas que conozco)
Creo que hay varios motivos:
  • Por una parte hay entidades en las que probablemente no se hacen los cálculos y se piensa, sin más análisis, que “tener unas fuentes de alimentación y unos ordenadores ‘sin usar’ es un derroche, hay que ahorrar y gastar lo menos posible”.
  • Posiblemente hay empresas que esperan que los empleados compensen las carencias de equipamiento con un esfuerzo extra: “Tendrás que trabajar este fin de semana para compensar esos días que has tenido el equipo estropeado”, “Esto tiene que estar en fechas, aunque haya que quedarse a cenar tiene que estar compilado y probado”,.. (lo que a la larga tiene otro coste mayor, descontento, pérdida de conocimiento cuando los empleados se “queman” y se van, y mala calidad por las prisas e imposibilidad de probar para entregar a tiempo).
  • Por último, creo que hay otro motivo, debido a la conversión de muchas instituciones en “reinos de taifas”, ya sea por el modelo organizativo y contable simplemente o porque determinados servicios se contraten a una empresa externa. Si un departamento tiene que dar un servicio (como ofrecer equipos informáticos) y únicamente se evalúa como criterio los costes de ese departamento, evidentemente cuanto menos gaste y menos tenga inmovilizado, tanto en potencia como en recambios, mejor. Si a ese departamento no se le aplica un acuerdo de nivel de servicio (S.L.A.) adecuado, que implique por ejemplo que ningún empleado podrá estar sin equipo más de dos horas, o que un proceso normal de trabajo (compilación, diseño, etc.) debe realizarse en menos de un tiempo X, lógicamente se está potenciando el ahorro y considerando como “eficaz” ese departamento, a costa de penalizar a los demás departamentos de la entidad.