Hechos que condicionan el resultado de un proyecto de desarrollo

El oficio de programador está lleno de mitos y estereotipos. Aunque si te paras y lo piensas un poco, ¿hay alguna profesión que no lo esté?

A pesar de que los programadores presumimos de tener una mente lógica y racional, no debemos subestimar el poder de ciertos mitos (pues habelos hailos). Son muchos los desarrolladores que dan por buenos ciertos tópicos que todos deberíamos intentar desterrar de nuestro subconsciente.

Uno de los mitos más conocidos es que aumentando el número de programadores que participan en un proyecto, éste se terminará antes. Esta teoría fue desmentida hace casi 40 años (en 1975) por Frederick P. Brooks en su libro "The Mythical Man-Month." Este libro es un compendio de ensayos los cuales giran en torno a una idea central “añadir más recursos HUMANOS a un proyecto retrasado hace que se demore aún más”. Las observaciones de Brooks están basadas en sus experiencias en IBM mientras administraba el desarrollo de OS/360, y si bien actualmente sus ejemplos pueden parecer obsoletos la esencia no lo está. 

Lamentablemente son mucho los programadores que, en lugar de seguir los consejos de nuestros ancestros, prefieren seguir creyendo en dichos mitos.

Desde aquí queremos felicitar a todos aquellos programadores que ponen su granito de arena cada día intentando desterrar de su entorno esos mitos, aunque a veces les suponga ser los parias de su equipo de desarrollo.
A continuación encontraréis los mitos más arraigados en la comunidad de programadores:

• MITO- 1: El cliente (o usuario final) sabe EXACTAMENTE lo que quiere y además es capaz de explicarte sus necesidades con todo lujo de detalles, sin que quede hueco para la imaginación.
  REALIDAD-1: ¿Os acordáis cuando de niños os sentabais haciendo una rueda y jugabais al “boca a boca”? De lo que decía el primero (cliente) a lo que le llegaba al último (programador) había un abismo. Aquí podríamos decir que el primero de la rueda se corresponde con lo que el cliente imagina, el siguiente es cómo traduce en palabras lo que ha imaginado, el siguiente sería lo que el programador interpreta y el último del corro lo que el programador hace. ¡Y no digamos si el programador no tiene conexión directa con el cliente y en el corro se mete en medio un comercial!
• MITO- 2: Aunque los requisitos del cliente cambian continuamente, dichas modificaciones pueden llevarse a cabo fácilmente porque nuestro software SIEMPRE es flexible.
  REALIDAD-2: Puede ocurrir que sea necesario cambiar los requerimientos a lo largo de la vida de un proyecto, la mayoría consecuencia del mito 1. Sin embargo, estas modificaciones serán más costosas a medida que el proyecto avance. Obviamente no es lo mismo introducir cambios en la fase de diseño, que en la de desarrollo que en la de implementación.
• MITO- 3: El mejor código es aquél que se escribe a la primera.
  REALIDAD-3: Suponemos que ese mito se forjó en un ambiente universitario o fue creado por algún desarrollador incauto en su época de aprendizaje. En cualquier caso es obvio que fue creado por alguien sin contacto alguno con el mundo laboral. Es como decir que un gran novelista publica lo primero que escribe, sin que la novela sea revisada por nadie (correctores,  maquetadores, editores) ni haya hecho varios borradores. Este mito fue desenmascarado por “el tío Bob” (Robert C. Martin) en su famoso libro "The Clean Coder".
• MITO- 4: Una vez que el programa funcione mi trabajo ha terminado
  REALIDAD-4: Si piensas de esa forma seguramente serás un programador tipo-1 o tipo -4.