Las absurdas leyes del mundo del software

¿Te has preguntado por qué personas tan inteligentes como los desarrolladores de software meten la pata tan seguido?. Hay gente que lo hizo. En este post pasamos revista a algunas de las leyes no escritas que describen el comportamiento de los profesionales de la informática.

Mi primera computadora fue una Commodore 64. Casi 30 kb de RAM eran para el sistema, lo que dejaba 32 kb para procesar textos, jugar, hacer la contabilidad de la empresa familiar y casi todo lo que hago con la computadora de 6 gb que tengo ahora. Eso deja abierta la pregunta ¿Los equipos actuales responden a las necesidades del software o el software usa más recursos de hardware porque están disponibles?

Siendo justos, los juegos no son los mismos, los gráficos tampoco tienen la misma calidad y hubiera sido imposible ver películas y escuchar música. Sin embargo, uno no puede dejar de pensar que hay programas que sacan versiones y consumen cada vez más recursos sin aportar realmente nada nuevo.

He aquí las causas.

Ley de Zawinsky

Jamie Zawinsky, desarrollador de Netscape, sostenía que todo programa va incorporando características hasta que es capaz de leer mails. Si no lo logra es reemplazado por otro que sea capaz de hacerlo.

Cuando lo enunció, el chiste estaba en que se refería a programas que originalmente no estaban pensados como clientes de correo. Dejó de ser gracioso cuando se descubrió que muchas aplicaciones de Google Play pedían permiso para acceder a componentes del teléfono y datos del usuario que no necesitaban para cumplir su función.

Algunos interpretaron esto como parte de los intentos de espiar a los usuarios. Pero probablemente se deba a la naturaleza humana de hacer algo simplemente porque puede hacerse.

El principio de Peter aplicado al software

Lawrence Peter se hizo famoso por afirmar que en una jerarquía, una persona asciende hasta llegar a un puesto para el que es manifiestamente incompetente. Pero también tuvo tiempo para decir algo sobre los proyectos complejos:

«Un proyecto complejo se volverá demasiado complejo para ser entendido incluso por sus propios desarrolladores.»

Principio del mínimo asombro

Publicado en el IBM Systems Journal en 1984, este principio afirma que:

«Si una característica necesaria provoca una gran sorpresa, puede ser necesario rediseñar la característica.»

En otras palabras, si una parte o todo el software es muy diferente a lo que el usuario estaba acostumbrado lo mejor es un rediseño. Lo ideal es esforzarse por lograr mejoras incrementales que sean lo suficientemente grandes como para ser impresionantes, pero lo suficientemente pequeñas para seguir siendo familiares para el usuario.

Lástima que Shuttleworth no lo tuviera en cuenta cuando lanzó Unity.

Ley de la entomología cibernética

El primer bug (bicho) de la historia informática era de verdad. Una polilla voló hasta uno de los relés de una computadora MARK II causando un error en el funcionamiento.

Siguiendo con la metáfora, la ley de entomología cibernética sostiene que siempre habrá un bug más.

Eso es algo que todos los usuarios de informática sabemos.  Por mucho que se testee un sistema operativo siempre aparece alguna falla que se descubre cuando es demasiado tarde.

Ley de Kernighan

Linux Adictos tiene instalado un complemento para asegurar que los autores escribimos en forma amigable para los motores de búsqueda. Lo detesté desde el primer día. Cualquier intento de escribir con un poco de vuelo literario es inmediatamente denunciado con un círculo rojo.  Con el correr del tiempo me acostumbré y son pocas las veces que tengo que hacer retoques.

A los programadores les pasa lo mismo, muchas veces están más interesados en demostrar su habilidad para codificar que en escribir un código más simple y fácil de entender y mantener.

De ahí que la ley de Kernighan sostiene que:

«Depurar es el doble de difícil que escribir el código en primer lugar. Por lo tanto, si escribes el código lo más inteligentemente posible, no eres, por definición, lo suficientemente inteligente para depurarlo».

La regla 90/90

Cualquier persona que haya iniciado un proyecto con fines de lucro en la vida real sabe que todo proyecto va a llevar el doble de tiempo y va a tener el doble de costo presupuestado, para obtener la mitad de la ganancia esperada.

El mundo de la informática tiene sus variantes de esta ley. Por ejemplo, un tal Tom Cargill dijo:

«El primer 90 por ciento del código representa el primer 90 por ciento del tiempo de desarrollo. El 10 por ciento restante del código representa el otro 90 por ciento del tiempo de desarrollo».

¿No quedó claro? Tal vez la ley de Hofstadter ayude:

«Siempre lleva más tiempo del que esperas, incluso teniendo en cuenta la ley de Hofstadter.»

Supongo que los desarrolladores de Ubuntu y Fedora deben saberlo. O al menos recordarlo cada 6 meses.

Ley de Brook

Los proyectos de software de código abierto suelen tener dos problemas; el financiamiento y la falta de colaboradores. A menos que el segundo no sea un problema. Según Brook:

«Agregar mano de obra a un proyecto de software que va retrasado, lo retrasará más.»

Es comprensible, No solo hay que poner al día a los nuevos codificadores. Habrá que documentar más cosas, se necesitará más burocracia para mantener a todos sincronizados, y probablemente haya peleas.

Y por supuesto no podemos olvidarnos del amigo Parkinson y su afirmación de que no importa con cuanto espacio vacio empieces. Siempre necesitarás más. El se refería de espacio de oficinas, pero lo mismo vale para RAM y espacio en disco.