Reglas para el desarrollo de tus propios programas.

La anterior tira probablemente no nos suene tan extraña, especialmente si alguna vez nos hemos embarcado en algún proyecto de cierto complejidad, que hayamos desarrollado más allá del individualismo. Acabo de encontrarme, por casualidad, una serie de normas. No son más que una mera anécdota, para nada deberemos tomarlo como un nuevo dogma, sin embargo espero que alguna consiga una sonrisa por su parte o al menos una cara asombro.

El artículo original lo podéis encontrar al final. Aquí os pondré las citas a mi parecer más interesantes ( y traducidas al español ).

Siempre lleva más tiempo del esperado, incluso cuando tienes esto en cuenta.

Añadir desarrolladores a un trabajo atrasado, es hacer que este se retrase aún más.

Esta anterior es realmente buena. Todavía recuerdo con amargura las largas noches "retocando" nuestros trabajos antes de las entregas en la universidad. Siempre te prometes que no va a volver a ocurrir, sin embargo...

Lo peor es mejor

Muestra como tu producto aparentemente inferior puede ser mejor para el usuario. Podría llegar a ser mucho más popular que una alternativa con mayores opciones pero menos comprensible.

Este caso es algo peculiar. Se me ocurren varios ejemplos. Por ejemplo, ffmpeg se me viene a la cabeza. Para los más despistadillos que no sepan lo que es, se trata de un programa que permite hacer mil operaciones con nuestros archivos multimedia. Se pueden cambiar de formato, resolución en el caso de los vídeos, tasa de transmisión de datos, etc. Entonces se preguntarán cual es el problema. Es evidente, este programa se puede utilizar únicamente por consola (tendría que buscar sobre los diferentes front-end's para esta aplicación), pero en cualquier caso estoy convencido de que si existe otra alternativa, agradable visualmente, aunque con muchas menos opciones, la gente lo preferiría por su sencillez.

El código refleja la organización de sus creadores.