El software inflado

La Ley de Wirth, enunciada por Niklaus Wirth en 1995, el artífice del lenguaje Pascal y sus derivados, dice lo siguiente:
“El software se ralentiza más deprisa de lo que se acelera el hardware”

Es un hecho evidente y notorio para todos. La mayoría de software que tenemos instalado funciona más lento que sus versiones anteriores. Lo vimos hace muchos años con Macromedia Studio 8 y Adobe CS3, que separados por un año y medio de diferencia, mostraron un incremento de tamaño del 15%. Puedes pensar que la diferencia entre Adobe Creative Suite 3 de marzo de 2007 y Macromedia Studio 8 de septiembre de 2005, estribaba también en el cambio de propietarios, y que por tanto requirió la integración de código adicional. No tiene demasiado sentido, porque también os expuse algo parecido entre Adobe Photoshop CS y CS2 (ahora Adobe Creative Cloud), donde veíamos unos aumentos similares, a pesar de utilizar el mismo obsoleto compilador en ambas versiones.

Es un hecho, que se conoce como software bloat o bloatware (software inflado), software que es cada vez más pesado y menos ágil, y que al poco tiempo de adquirir un hardware de última generación, parece que se arrastre.

Personalmente, siempre he valorado notablemente la eficiencia y el rendimiento de mis programas. No tenéis más que ver las reflexiones sobre FileOptimizer, donde el énfasis fue en conseguir justo lo contrario. Un código más eficiente y compacto, pese a todas las nuevas características y añadidos. En el mundo empresarial, es algo más difícil de lograr, puesto que la optimización, suele tener una relación exponencial con el coste. Sale mucho más barato implementar una nueva característica, que optimizar el programa. Por supuesto, a nivel comercial, vende mucho más esa nueva característica, que las mejoras de rendimiento.

El software inflado

Para poneros en contexto, el análisis de rendimiento de un software, es decir, su estudio, las pruebas empíricas, la simulación de carga, los juegos de pruebas, y el profiling (perfilado); son solamente tareas tediosas, que tienen un impacto en el coste bastante limitado. Pero una vez que conocemos los cuellos de botella de nuestra aplicación, lo siguiente es solventarlos. Refactorizando, obtendremos un código más limpio y probablemente más eficiente, pero a partir de ahí, no tendremos más remedio que reescribirlo. Cuanto más código reescribimos, más errores o bugs introducimos, y por tanto más pruebas y depuración tendremos que realizar. Así que volvemos a estar ante la ley del 80/20, donde un 20% de mejora del rendimiento, puede llevarse el 80% del esfuerzo total. Imaginaros que os dicen que el nuevo Word, será un 20% más rápido. Abrir un documento ya no será 10 segundos, sino solamente 8, pero que en vez de costar 100€, va a costar 180€. ¿Lo pagaríais? La respuesta es que probablemente no, así funciona la industria. Mientras que si os dijeran, que ahora Word, puede por ejemplo exportar documentos en 3D, esa nueva característica, tal vez si valiera el aumento de precio subjetivo.

La rueda seguiría en funcionamiento, y tendríamos un Word, que exportaría documentos en 3D, con nuevo código, que a efectos prácticos casi nadie utilizaría, pero que todos cargaríamos. Word sería más bloatware todavía, pero sus responsables, habrían conseguido venderlo un 80% más caro. La culpa no es directamente de Microsoft en este ejemplo, fuimos los usuarios los que nos negamos a pagar ese precio por una mejora de rendimiento de 20%, así que al final, ellos hicieron lo que nosotros queríamos. Realmente, como usuarios, no somos conscientes del coste que tiene la optimización del software. Puede que nos quejemos frecuentemente sobre la falta de velocidad, o sobre el consumo de memoria. Tal vez parezca que nos importa muchísimo. Pero cuando comparamos el coste que ello tiene, pasa a ser una segunda prioridad. No es que los desarrolladores sean malas personas, y no les importe que su programa funcione lento, lo que ocurre es que sólo tienen dos manos y un cerebro, y si hacen una cosa, como la exportación a 3D, no pueden hacer otra, como la de optimizar. Ten por seguro, que si pudieran, lo harían.

A todos nos gustaría que Windows funcionara el doble de rápido, y cuando intentas explicar que hacerlo, probablemente implicase que costase 10 veces más, ves caras raras de incredulidad. En cambio, todos entienden que un coche que corra el doble que otro, será 10 veces más caro. Como decía al principio, la relación entre eficiencia y esfuerzo, es siempre exponencial. Por otro lado, optimizar es una tarea engañosa. Por su definición, es un proceso sencillo de hacer, cuando la implementación dista de ser óptima. Es decir, a un código pésimo, es relativamente fácil sacarle mejoras. Pero a medida que lo vamos puliendo y arreglando, resulta cada vez más complicado.

Si aún seguís leyendo, la pregunta que tendréis en este momento, es ¿porqué si Windows XP era tan rápido, Windows 10 va tan lento ahora? Bien, en primer lugar, Windows XP, no es tan rápido. Acuérdate cuando salió, que ya te parecía mucho más lento que Windows 2000 o que Windows NT. Lo que ocurre es que Windows XP, si que es mucho más rápido en el hardware de hoy en día, que no existía cuando salió. Seguramente dirás, que no necesitas la mayoría de características nuevas de Windows 10, y que seguirás con XP. Pero en realidad te refieres a que no necesitas lo que se ve. Porque lo que hay dentro, si que lo necesitas. Desde el soporte de nuevo hardware, que ya no funciona en XP, porque recuerda que era un hardware que no existía en 2001, hasta nuevas funciones que necesitan las nuevas versiones de los programas que usas. Sin embargo, en la mayoría de casos, podrías seguir usando Windows XP y Office 2003, lo que ocurre, es que no quieres, y por tanto, tienes que resignarte a pagar el precio del bloatware.

Siempre he dicho, que 10 años en un software, equivalen a 50 años en cualquier otro tipo de industria. Como entorno puramente tecnológico, y donde lo que se vende, son intangibles, el ciclo de vida se acelera. Esto quiere decir, que en 10 años, el código ha pasado por muchas manos. Algunas que han sido buenas, y otras que no lo han sido tanto. Ha pasado por muchos retos comerciales, en cuanto a enfoque y reenfoque, y seguramente también ha sufrido retrasos inesperados, recortes de presupuesto y recortes de plazo. Cuando haces algo por afición, estas trabas, pueden no tener tanta importancia, pero cuando tu sustento depende de ello, son problemas importantes.

Si no consigues desarrollar algo más barato que la competencia, no tendrás mercado. Si no lo consigues liberar a tiempo, nadie lo comprará. Así que dices, bueno, ya lo optimizaremos más adelante. Esta procrastinación, acaba en que el proyecto nunca se optimice, nunca se pula, nunca se ajuste. Porque resulta que hacerlo, parece que tiene más interés en el desarrollador, que en el mercado. Por supuesto el público lo aceptaría gustosamente si fuera gratis, pero no lo es, porque hacerlo, ha requerido mucho esfuerzo extra.

Entonces el tiempo sigue pasando, y vives lo que se llama software rot, o erosión del software. Lo que estaba mal, está cada vez peor, porque ahora tiene que sostener las nuevas funciones que se han ido añadiendo, porque el código lo han escrito entre más personas, es más difícil de comprender, y al mismo tiempo se llena cada vez más de desastres. Y en algún momento de su decaimiento, te das cuenta que hubo otro problema, y es que el enfoque, no fue el correcto. Escribir software es innovar, así que por definición, todos somos inexpertos, porque es la primera vez que hacemos algo parecido. Por mejores gestores, o programadores que seamos. Aunque hay algunos que pueden vivir repitiendo siempre lo mismo, no es la mayoría, y además resulta aburrido. Llega el momento en que has ganado experiencia en ese proyecto, y entonces te das cuenta que lo harías de otra forma. Esa otra forma, sería mucho mejor, más limpia, más clara, y soportaría sin problemas todas esas nuevas funciones que se añadieron. Claro que a toro pasado, también es fácil de ver, porque jamás hubieras pensado que Word tuviera como requerimiento, que exportar documentos en 3D, y lo más seguro, es que ni siquiera estuviera preparado para ello, y tuvieran que hacérsele bastantes cambios de última hora (ñapas).

El problema de hacerlo de otra forma, es que no hablamos de reescribir algunas partes, sino de tirarlo, y empezar desde cero. Claro, tendremos la nueva experiencia y los nuevos conocimientos, en el mejor de loas casos aprovecharemos un 10% o un 20% del código que ya teníamos. Pero todo el resto, será un producto completamente nuevo. No solamente partiremos de un enfoque inicial que ahora si que será óptimo, te librarás del código malo que escribió el becario de turno, del código ininteligible que nadie sabe para que sirve, y que escribió el empleado desganado, y de toda esa programación que ha ido creciendo poco a poco para aguantar funciones que no se contemplaron desde el principio. Además sabes que por más que optimices un mal enfoque o algoritmo, siempre será ineficiente. Porque por más que escribas un algoritmo de ordenación basado en el método de la baraja en ensamblador, usando instrucciones AVX, al final, una implementación de quicksort, aunque la hagas en Javascript, será más veloz.

Sabes que tarde o temprano tendrás que hacerlo, cada vez es más caro mantener una nueva versión del software, cada vez es más dramático. Pero no pienses que hacerlo de nuevo será una ventaja. No vas a tropezar dos veces con la misma piedra, y no cometerás los errores del pasado. Pero valora el riesgo de que cometas errores nuevos. Fotografix, era un ágil visor y editor de imágenes. La nueva versión, reescrita desde cero, ha optado por .NET, ya nunca será tan buena como lo fue la anterior.

Finalmente, tendrás esa nueva versión reescrita desde cero, o casi desde cero. Si vuelves a tener suerte, volverá a liderar el mercado, pero recuerda que esto ha ocurrido con poca frecuencia, y cuando algo se empieza de nuevo, surgen nuevos riesgos. De cualquier modo, volverán a pasar 10 años, y tendrás otra vez esos problemas. Nuevos requerimientos que no contemplaste al escribirlo desde cero, nuevo hardware que en su momento no existía, y otra vez malos programadores que han ido pasando por el código. El ciclo se repetirá nuevamente, y volverás a tener code bloat.

No hay soluciones mágicas, ni balas de plata. Cualquiera que prometa una mejora sustancial, con un esfuerzo pequeño, simplemente miente. De ser cierta, todos la aplicarían. Me recuerda mucho a los charlatanes de antaño. Yo era un niño, y me preguntaba cómo era posible que si ese quitamanchas era perfecto, siguieran existiendo tintorerías. La denominada Ley de Parkinson, te garantizará que sólo la optimización pueda agotar tu presupuesto completo. Y lo que es peor, que una vez agotado, ni siquiera la hayas completado.

Si no haces nada, será casi peor. Ese código será cada vez más difícil de mantener, y cada vez te costará más sacar una nueva versión. Incluso si piensas que el rendimiento ya no es problema, porque conoces la Ley de Moore, debes saber que no importa. Da igual que la capacidad del hardware se doble cada 18 meses, porque lo que quizás no conoces es la Paradoja de Jevons, un término económico, pero que se aplica cada vez más a la complejidad del software. Viene a decir, que cuanto más capacidad hay, o más barata es ésta, mayor demanda de la misma. O sea, que tu programa siempre se relantizará más deprisa de lo que aumente el hardware, como decía Wirth. Los ejemplos anteriores sobre Microsoft, fueron en realidad intencionados, porque después de Wirth, Bill Gates, lo enunció de un modo similar:
“La velocidad del sofrware comercial, generalmente se reduce en un 50% cada 18 meses, contrarestando los beneficios de la Ley de Moore.”

No deja de ser de gran importancia que Gates lo admitiera, él mejor que nadie lo conocía. De nuevo, daros cuenta, que se refiere a software comercial, es decir, aquel que debe ser vendido. El que no lo es, como os explicaba con FileOptimizer, puede vivir al margen de todo ello. Si me apetece invertir mi tiempo en optimizar FileOptimizer, puedo permitirme ese lujo. Por eso en el software gratuito y libre, se dan muchas paradojas. Desde joyas increíbles, que aportan cosas que los títulos de pago no ofrecen, hasta desastres de cualquier tipo.

10 comentarios en “El software inflado”

  1. Lo clavas, tío, menos en una cosa, o al menos he entendido que dices lo contrario a esto: reescribir desde cero es malo, muy malo.

    IMHO, la solución es la refactorización y la mejora incremental del código viejo. Lo digo por experiencia, habiendo currado con Embarcadero y ahora mismo, con un proyecto propio de unos 4.5 millones de líneas de código en C++ que me como yo solito.

  2. Sabes que en esto muchos desarrolladores (y programadores, entre ellos yo -no me gusta el término desarrollador, no se por qué :D- coincidimos, y tu frase en donde resumes la razón de ello es genial porque lo sintetizas muy bien, permíteme “entrecomillártela” porque no puede explicarse mejor: ” la optimización, suele tener una relación exponencial con el coste. Sale mucho más barato implementar una nueva característica, que optimizar el programa. Por supuesto, a nivel comercial, vende mucho más esa nueva característica, que las mejoras de rendimiento“.

    Por otro lado, estoy muy de acuerdo contigo en que las versiones betas, tests, profilings y blablabla patatím patapúm… requiere sus recursos e inversión de tiempo y dinero que a veces no parece compensar (a la mayoría de aplicaciones comerciales), pero esto tiene sentido cuando son proyectos empresariales grandes o enormes suites. En aplicaciones medias o pequeñas, es simplemente efocarlo para programar eficientemente, y mientras lo desarrollas, ya tienes eso en cuenta. Por desgracia, ni en mis tiempos de estudiante, ni ahora, se aprecia eso, no vi ninguno de mis profesores que se fijara en cuanto espacio ocupaba, tiempo de carga y demás, la mayoría, por no decir todos, lo único que querían era verlo “guapo” y verlo trabajar.

    Personalmente odio el software comercial. La mayoría de cosas que utilizo son libres o de código abierto, o hechas por mí, como los editores de texto o los visualizadores gráficos. La razón es que, como bien señalas en la segunda parte de tu artículo, todo el software comercial tiene que venderse, entonces ¿qué ocurre?, que funciona muy penosamente, y que tiene muchos bugs. No es que la gente sea tonta, la gente lo compra, por supuesto, porque hay que tener en cuenta que una grandísima mayoría de los consumidores no sabe diferenciar un procesador de textos o cualquier suite de otra, simplemente usa la que le han puesto cuando se compraron “el bicho”, o la que les instaló la empresa, el amiguete de turno o la primera que encontraron o vieron por ahí. Y, principalmente -lo sé por la gente que conozco- la que haya sido más fácil de instalar. Punto. No buscan más.

    Sin embargo, y como explicas genialmente, los otros desarrolladores de aplicaciones “libres” pueden dedicarse e invertir su tiempo en mejorar la eficiencia de su software, pasando por encima de todo lo demás. ¿Que en lugar de cien mil lo descargan cien? Pues vale, peor para los que no lo hayan hecho. ¿Que lo acabas usando tú mismo? Pues genial, porque funciona como a ti te gusta.

    Pondré un ejemplo de todo esto (y perdón por el rollo, pero es que me he acordado :D); una vez fui a una celebración y estuve encargado de las proyecciones. Para manejarlas, tenían un ordenador de hace bastantes años que en su día había llevado Windows XP. Vale, pues fue un caos y casi no podemos empezar la proyección porque el ordenador no podía con todo, resulta que le habían instalado Windows 10, la última versión de Powerpoint junto con el último Office porque alguien -obviamente con poco conocimiento de informática- creía que con las últimas versiones de software, el hardware antiguo funcionaba mejor. Este es un error que se comete una y otra y otra vez, y nadie aprende. Les intenté explicar que en un ordenador de ese tipo tenía que llevar un software de su época, y que, con suerte, podría tirar de él “y gracias”. Por supuesto me miraron como si hablas en chino y aún siguen con lo mismo. No entiendo, no concibo y aún no me entra en la cabeza, cómo alguien puede pensar que software de hoy puede solucionar problemas de hardware de ayer, ¡no tiene nada que ver!

    Es como cuando actualizas tu cámara digital con un nuevo firmware, y luego la gente flipa porque te dicen: “¡anda, si antes arrancaba en dos segundos, y ahora tarda diez!”, y dicen que les han engañado y creen que ya se ha quedado obsoleta y ya quieren tirarla y comprar otra. Pues no, todo esto tiene su razón de ser, que la has expuesto perfectamente en este artículo. Por desgracia, muchos seguirán empeñados en creerse que el software puede actualizar su ordenador o su dispositivo como si fuera nuevo, y a excepción de correguir bugs -que eso también está por ver- o fallos graves de firmware, en la mayoría de las ocasiones estaría cometiendo un error quien piense en actualizarlo para hacerlo mejor. De hecho, hará que funcione peor.

  3. Saludos,

    – Adicionalmente esta el adware, o lo que suelo considerar como adware, como servicios auto-actualización, el muy famoso: “enviar anónimamente datos y estadisticas de uso …”, “compartir la experiencia de usuario …”, publicidad, etc. Caracteristicas y funcionalidades que están ahí pero desactivadas (aunque esto suele ser bueno si se sabe activarlas por algún medio XD)

    – Al final lo ideal sería explicar porque el cambio abrupto de peso, ya comente alguna vez como Gimp 2.6 se engordó al triple de peso y aumentó su tiempo de carga x5 veces x_x.

    – Para mí un mundo ideal sería el poder elegir que quiero y que no de un software, similar al instalador modular de Avast, K-Lite, y otros que en menor medida dejan elegir y configurar lo que se quiere. Ni que decir de como van las Apps de Android, cada vez más adware, más peso, más permisos, es una locura.

  4. Javier Gutiérrez Chamorro (Guti)

    Sí y no rfog. Lo que digo, es que a veces, en casos puntuales, reescribir desde cero, si que es la solución, llega un momento, que eso puede ser más rápido que refactorizar todo. Pero también remarco, que una reescritura completa, por más que hayamos aprendido durante el proceso, no nos garantiza que no cometamos esos mismos errores u otros distintos. En el mundo de la programación, la frase de “esto hay que tirarlo”, se escucha tanto como en la albañilería la de “¿quién le ha hecho eso?”. Es la solución fácil, tirar, y hacer de cero, pero no siempre la óptima.

  5. Javier Gutiérrez Chamorro (Guti)

    Claro bianamaran. La gente piensa que el software es mágico. Lo actualizo, y mi hardware de hace 10 años, ahora hace más cosas, pero esas más cosas, tienen un coste. Un coste que el hardware moderno puede pagar, pero el antiguo no puede. Mi anécdota más reciente sobre eso, es con un sintonizador de TV Sveon. No me avergüenza decir que tengo una tele CRT, que es analógica, y por eso necesita sintonizador, y que casi apenas la veo. Pero si que veo contenidos descargados por internet.

    El caso es que recientemente mejoraron el soporte de formatos que el sintonizador puede reproducir por USB. Es un aparato que costaría unos 40€ hace 3 o 4 años. Así que demás han hecho actualizando el software/firmware. Bueno, lo habrán actualizado los chinos que hicieron el hardware, y ellos lo han traducido, pero vamos que ha costado trabajo a ambos. Pues ahora, el resto de la interfaz va mucho más lento, tanto, que he downgradeado (rebajado?) a la versión anterior. De momento no tengo problemas con el formato de vídeos que uso, no necesito la nueva versión, y no me apetece cargar con esa sobrecarga.

  6. Javier Gutiérrez Chamorro (Guti)

    Para mi EdSon, es muy distinto el adware, que básicamente hace que el software sea pesado, porque incorpora unas API de publicidad, que son habitualmente más complejas que el propio programa, que el envío de estadísticas anónimas, que son unas pocas lineas de código más, y que si se tienen en cuenta (y yo lo hago), sirven al desarrollador para ver que es lo que más se usa y lo que menos, y así poder mejorar lo más requerido, y poder dejar de lado o eliminar lo menos útil.

    No debemos olvidar, que el software ligero, no es sólo optimización, sino eliminar también ese código que ya nadie usa, o que no es necesario. Por ejemplo, hace un año, FileOptimizer tenía aún en el código algunos parches para bugs de RAD Studio XE, o de RAD Studio XE4. Ya nunca lo voy a compilar con esas versiones, no hace falta cargar con ese código innecesario, versión tras versión. Puede que nos de pena eliminar código que es nuestro, pero así es la vida del software. No todo es añadir, y modificar, sino también eliminar.

    Coincido en el instalador de Avast!, muy logrado y fácil de usar. Pero esa modularidad, es también una complejidad extra en el desarrollo. Tu programa debe estar basado en una arquitectura de pueda cargar componentes dinámicamente (o librerías, o DLL, o como queramos llamarlo), y eso es bastante más complejo. Por ejemplo, FileOptimizer aprovecha algunas características de Windows 8/10 si están disponibles. Cargar esa DLL dinámicamente, requiere 5 a 10 veces más código, que usarla directamente. Debemos comprobar si está disponible o no, y en caso de que no lo esté, porque usamos Windows Vista, por ejemplo, usar la versión alternativa. Es decir, es complejidad, y software hinchado, pero a mi modo de ver, porque en este caso concreto aporta ventajas.

  7. bianamaran, tampoco el software libre está exento de aumento de funciones sin optimización. Un ejemplo puede ser KDE.

  8. Javier Gutiérrez Chamorro (Guti)

    Rafael R. no se si el caso de KDE es más bien culpa de Qt de que de el propio KDE. En todo caso, y dado que inflarse, es la tendencia natural en el sofware, sí que es cierto, que el software libre, o digamos, el no comercial, puede permitirse el lujo de optimizar y eliminar funciones. Obviamente no es algo que ocurra a menudo, pero al menos tiene esa posibilidad y esperanza.

  9. Cuando Microsoft lanzó window vista requería recursos que en el mercado no existían, excepto en equipos de última generación, los cuales por supuesto caros. Así que creo que muchas veces se lanza un software con el funcionamiento del equipo en curso, pero que a la mejor no corresponden con el mercado.

  10. Javier Gutiérrez Chamorro (Guti)

    Windows Vista es un buen ejemplo Manuel. Su desarrollo tuvo tantos problemas, que se retrasó el doble de lo estimado. No estaba en posición de ser optimizado. A eso se le juntó, que sus nuevas características, requerían más hardware. Y así fue, un producto que requería un hardware que no estaba disponible ampliamente.

    Por suerte la base era buena, y tras ser optimizado consiguieron Windows 7, consumía menos memoria, menos espacio en disco, y tenía todavía más cosas que Vista.

Responder a Javier Gutiérrez Chamorro (Guti)Cancelar respuesta