Ley de Wirth

0

Una de las leyes que más me gusta de nuestro mundillo, y que quizás pasa desapercibida es la ley de Wirth. Es el otro lado de la famosa ley de Moore y creo que es bastante ilustrativa de algunos conceptos que nos rodean.

No hay un enunciado claro para la ley de Wirth pero entre los más reconocidos tenemos:

Software gets slower faster than hardware gets faster

El software se vuelve lento más deprisa que el hardware se vuele rápido

Todos conocemos la ley de Moore, que nos dice que el número de transistores en los circuitos integrados se duplica más o menos cada dos años. Hay quien habla de 18 meses, porque lo mezclan con otra predición de David House (un directivo de Intel) que predecía que la capacidad del hardware se doblaba cada 18 meses. De hecho cuando comúnmente se habla de la ley de Moore, la mayoría nos referimos a la cita de David House.

Esta ley tiene múltiples nombres, porque todo mandamás de Sillicon Valley se la acredita. Asi se puede referenciar como la ley de Page, la ley de Gates o la ley de May. Y también muchas espresiones. Quizás mi favorita sea:

Lo que Andy nos da, Bill nos lo quita

Referenciando a a Andy Grove de Intel y Bill Gates de Microsost.

Idas de olla aparte, el hardware cada vez es más potente, pero el software es cada vez más lento. ¿Por qué?

El ejemplo más común era el arranque de Windows, pero los chicos de Microsoft se han puesto las pilas y entre las mejoras que han introducido y los discos SSD y M.2, la verdad es que queda atrás lo de más de un minuto arrancando. Pero todavía hay muchas otras cosas: El tiempo que tarda en abrirse word. O lo sobrecargadas y lentas que son algunas web famosas. Y mi favorito, la velocidad percibida por un usuario de como va un iPhone.

Todo se vuelve más lento, y el señor Wirth nos adelanta que somos los desarrolladores de sofware los que conseguimos ralentizar nuestro código más rápido de lo que el hardware mejora.

Creo que un gran motivo es lo que se llama el software bloat (inflado). El software inflado consiste en añadir funcionalidades que realmente no aportan valor pero que ralentizan el software. Es un caso claro de feature creep, o de gold plating. Si seguimos la ley de Pareto, el 80% de los usuarios usa el 20% de las funcionalidades.

Pero no es solo eso, sino que otra causa de esta pérdida de rendimiento, está en que mucha gente considera que hoy en día es mejor poder añadir funcionalidad rápido, y ganar en capacidad de operación que en rendimiento. Ya os lo conté en el artículo sobre “segundos, neuronas y tornillos“, en donde dejo claro que la mayoría de veces se nos pide entregar rápido, y con el menor coste de programadores, dejando de lado el consumo de hardware que tengamos.

Y en esa línea también está la calidad del código. Tener una alta calidad, a veces nos lleva a determinados patrones de diseño que consumen más recursos. Patrones que nos hacen consumir más recursos ya que añaden capas de abstracción o comunicación entre sistemas.

El lado oscuro de Wirth

Pero muchos de estos motivos que os he dicho antes para tener un software más lento son “aceptables”. El otro motivo, y que desgraciadamente se puede ver comúnmente, es la falta de interés. No es que se quiera entregar rápido. No es que se quiera un código ordenado. Ni tener diez mil funcionalidades extra. Es simplemente que hay mucho programador que simplemente no le importa lo que consuma su software. Desidia, falta de interés o simplemente de capacidad que consiguen que el señor Wirth siga teniendo razón. Y como ese performance no es a priori necesario, nadie les llama la atención ni les educa.

Poner enteros de 32bits para todo (incluso flags). Usar strings hasta la saciedad, incluso para enumerables. Dejar memory leakages pululando y programar reinicios periódicos. O bucles que piden y piden lo mismo a base de datos. Todo esto no es más que el resultado de programadores que ni les importa ni les interesa el rendimiento de lo que hacen.

Pero claro, la bola se hace grande con el paso del tiempo. Y si la empresa crece y el tiempo pasa, cada vez hay más usuarios conectados, más transacciones en paralelo y tablas con más registros en la base de datos. Y ahí, el señor Wirth nos da en toda la cara demostrando que ese trabajo que se hizo hace años no es tan escalable, y sólo porque no se prestó atención al rendimiento.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios