Regla N°14 de la Ingeniería de Software: Evita la ceguera voluntaria

La ceguera voluntaria es ignorar de forma deliberada situaciones que si bien son perjudiciales, no suponen un daño inmediato, con lo que no se hace nada para corregirlas, convirtiéndose en una posible situación catastrófica a futuro.

Ejemplo de ceguera voluntaria en la serie Silicon Valley, Capítulo 03x05.

Aunque pudiera parecer absurdo intentar ignorar o omitir posibles problemas dentro del desarrollo de software (o realmente en cualquier tipo de proyecto) es algo bastante común.

Cuando aparecen problemas en mitad de un desarrollo y no son atacados y mitigados cuando son pequeños, aumentaran de forma progresiva hasta ser de tal tamaño que afecte al tiempo, calidad o costo del proyecto.

Lo elementos que más se suelen ignorar son:

• Retrasos en el desarrollo del software: El producto saldrá claramente después de la fecha estimada, sin embargo ninguna alerta es disparada, haciendo creer al cliente que tendrá su sistema cuando se le indico. Aparentemente nadie quiere decir la palabra "retraso" en voz alta, aunque es algo claramente palpable.
  
  
• Problemas tecnológicos: El equipo no tiene la capacidad técnica suficiente para llevar a buen término el sistema, ya sea por una sobreestimación de sus posibilidades, o porque directamente se construyo un equipo sin la preparación necesaria.
  
  
• Problemas de recursos: No hay algún factor tal como dinero, tecnología necesaria (teléfonos, tablet o computadores) o gente disponible.
  
  
• Problemas de integración de equipos: Aquí simplemente el equipo (de personas), no puede trabajar juntos, ya sea porque no tiene una buena relación o porque tienen una idea del trabajo tan individualizada que no son capaces de entender el concepto de trabajo en equipo.
  
  

Hay que entender que la ceguera temporal es algo que se da en todos los niveles, el programador puede omitir datos críticos, pero un buen líder de proyecto debe detectar omisiones y faltas al plan de desarrollo y buscar la forma de mitigarlos y sobretodo que emerjan a la luz, y estén claros, es decir asegurarse que hayan sido comprendidos (al nivel jerárquico que corresponda). Un líder de proyecto que ignora lo que ocurre en su equipo y en la construcción de un sistema, es un mal líder de proyecto y posiblemente un irresponsable que echarla la culpa del fracaso de "su" sistema a otras personas.