Como en todos los campos, en el mundo de la programación y el desarrollo software han ido apareciendo (a partir de la experiencia de muchos) algunos principios, reglas y leyes que conviene tener muy presentes al empezar un nuevo proyecto de desarrollo. Veamos algunas de las más importantes:

Contents

La ley de Brooks

Esta ley seguro que la habéis vivido en vuestras propias carnes:

Añadir personal a un proyecto que va tarde, sólo consigue que se retrase aún más.

Esta ley la formuló en el mítico y muy recomendable libro:  The Mythical Man-Month : Essays on Software Engineering

La ley de Conway

Las organizaciones acaban diseñado sistemas que son un reflejo de su propia estructura organizativa interna

Esto puede ser bueno o malo. Dependiendo de lo bien estructurada que esté la organización. Pero en todo caso, sí es un problema cuando se quiere adoptar un nuevo paradigma de desarrollo. Por ejemplo, si se quiere introducir un proceso basado en el desarrollo low-code habrá que primero cambiar la organización en sí misma.

La ley de Gall

Siempre empezar por construir un sistema simple que funcione. Créeme, escucha a Gall:

Un sistema complejo que funciona siempre es una evolución de uno más simple que ya funcionaba. Un sistema complejo diseñado partiendo de cero nunca funcionará y nunca podrás arreglarlo para que acabe funcionando.

La ley de Eagleson

Un buen recordatorio de la importancia de documentar:

Cualquier trozo de código que no has mirado en 6 meses o más, bien podría haber sido escrito por cualquier otro

Habrás perdido ya cualquier recuerdo del porqué lo escribiste de una u otra manera y sólo te quedará mirar tus propios comentarios para entender tu “yo pasado”.

La ley de Hofstadter

Esta se combina casi siempre con la de Brooks. Dice:

Un proyecto siempre tarda más de lo que esperas. Incluso cuando tienes en cuenta la Ley de Hofstadter

Que viene a realzar lo complejo de estimar de forma adecuada la complejidad de un proyecto, incluso cuando sabemos de antemano que va a ser complejo e intentamos tener ese factor en cuenta.

El principio de Knuth

La optimización prematura es la madre de todos los males.

Y además una de las razones por las que parece que los proyectos software nunca acaban, incluso parece que estamos ya a punto.

La ley de Linus

Sí, el Linus de Linux, aunque no la ley no es suya sino que fue bautizada así en su honor por Eric S. Raymond en el libro The Cathedral and the Bazaar. Dice:

Si hay suficientes ojos mirando, todos los bugs son fáciles de encontrar

Esta frase la utiliza para defender las bondades del software libre. Y en parte tiene razón aunque se llega pronto al número máximo de ojos útiles. Es decir, es cierto que tener alguien que te revise el código ayuda mucho a encontrar errores pero a partir de un cierto número de revisores (en general, bajo), poner más gente a mirar no siempre sirve. A veces hasta distrae.

La regla de Pareto

Esta es una regla universal pero con muchas aplicaciones también en el mundo de del desarrollo. Por ejemplo:

El 80% de los errores vienen del mismo 20% del código

El primer 80% de las funcionalidades las implementarás en el primer 20% del proyecto. Para el resto, te pasarás el 80% del tiempo.

(esta segunda tiene una versión más malvada, la regla 90-90 que dice que para el primer 90% de la funcionalidad tardarás el 90% del tiempo, para el último 10% tardarás otro 90%).

La ley de Parkinson

La duración de un proyecto se expande hasta ocupar todo el tiempo disponible

con lo que dejar un final abierto (por ejemplo debido a nuestra incapacidad para estimar la duración, Ley de Hofstadter) no ayuda tampoco a acabar el proyecto.

El Principio de Peter

Un problema en todo equipo de desarrollo

Toda persona es promocionada hasta llegar a su máximo nivel de incompetencia

La ley de Wirth

Otro de los clásicos. Ésta la experimenté de joven jugando a videojuegos. Por mucho que iba mejorando las prestaciones del ordenador siempre tenía problemas con los juegos que iban saliendo al mercado, y es que:

Las mejoras de rapidez del hardware no compensan la creciente lentitud del software que se escribe hoy en día

Y aún hay más, ¿recomendáis vuestras leyes o principios preferidos?