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.

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.