(Mayormente) útiles reglas de desarrollo de software

Se fue junio como por un tubo, y si bien han habido varias noticias en el entorno open source, muchos ya se han encargado de ellas. La salida de Mozilla Firefox 3.5, VirtualBox 3.0, y recientemente VLC 1.0 y algunas más que no recuerdo.

Aviso, de paso, que si alguno quiere tener Firefox 3.5 en Debian amd64, puede obtener el fuente y compilarlo, o bien aprovechar los paquetes pre-release de Iceweasel 3.5 que Mike Hommey tuvo la delicadeza de poner a nuestra disposición.

Pero lo de hoy es una breve traducción de un post que ayer publicaron en Pingdom titulado "Quirky but (mostly) useful software development rules", recordando reglas con las cuales adhiero bastante.

Regla del noventa-noventa

El primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo.

(puede parecer equivocada, pero es así)

Ley de Hofstadter

Siempre lleva más tiempo del que uno espera, incluso si se tiene en cuenta la Ley de Hofstadter.

Ley de Brooks

Agregar gente a un proyecto atrasado, lo atrasa aún más.

Ley de Lister

La gente, presionada por el tiempo, no piensa más rapido.

Método MoSCoW

Una técnica para priorizar la entrega de requerimientos durante el desarrollo. MoSCoW significa:

[M]UST have this. -- DEBE tener esto.
[S]HOULD have this if at all possible. -- DEBERÍA tener esto si es posible.
[C]OULD have this if it does not affect anything else. -- PODRÍA tener esto si no afecta otra cosa.
[W]ON’T have this time but WOULD like in the future. -- NO tendrá esto ahora pero PODRÍA tenerlo en el futuro.

Principio KISS

«Manténgalo breve y simple» («Keep It Short and Simple»), en la forma más educada.

Ley de Gall

Un sistema complejo que funciona es siempre una evolución de un sistema simple que funcionó.

Peor es mejor, o estilo Nueva Jersey

Describe como un producto "inferior" puede ser mejor desde la perspectiva del usuario. Un software limitado pero fácil de usar puede ser más popular entre los usuarios que un software "mejor", pero más abarcativo.

Décima regla de Greenspun

Cualquier programa C o Fortran lo suficientemente complicado contiene una implementación ad-hoc, informalmente especificada, lenta y llena de errores de la mitad de Common Lisp.

Ley de Zawinski

Cada programa intenta expandirse hasta que puede leer mail. Aquellos programas que no pueden expandirse de esta manera se reemplazan por otros que sí pueden.

Ley de Linus

Dado un número suficientemente elevado de ojos, todos los errores se convierten en obvios.

Ley de Murphy

Clásica: Si algo puede salir mal, saldrá mal.

Ley de Sutton

Ve a donde está el dinero.

Es decir, al diagnosticar un problema, uno debería confirmar primero si se trata del diagnóstico mas común, p.ej. probando la solución más evidente. Toma su nombre del ladrón Willie Sutton, que atracaba bancos "porque ahí es donde está el dinero."

Ley de Wirth

El software se ralentiza más deprisa de lo que se acelera el hardware.

Ley de Conway

Una pieza de software refleja la estructura organizacional de la organización donde se produjo.

Principio de Hollywood

No nos llame, nosotros lo llamaremos.

En vez de que el programa ejecute al sistema, el sistema ejecuta su programa.

Principio de Dilbert

Los trabajadores más incompetentes son promovidos sistemáticamente al lugar donde pueden hacer menos daño: la administración.

Fuente: Quirky but (mostly) useful software development rules (Pingdom) y Wikipedia