archivo

Archivos diarios: agosto 1, 2011

Harlan D. Miles fue profesor del Instituto Tecnológico de Florida aunque también tuvo una amplia experiencia en el sector privado tanto trabajando por cuenta ajena en IBM como siendo fundador de su propia empresa de desarrollo de software.

Mills destacó por su contribución al campo de la ingeniería del software mediante la integración en la misma de principios estadísticos y matemáticos orientados a la obtención de un software sin errores. Su trabajo fue utilizado en el desarrollo de sistemas de información en sectores críticos como la medicina, comunicaciones y energía.

El IEEE reconoció su trabajo mediante la creación en el año 1999 del premio Harland D. Mills.

Con toda esta experiencia, Mills sabía muy bien lo que decía cuando realizó la siguiente reflexión (traducción libre): “La única manera de que los errores aparezcan en un programa es que el autor del mismo los haya colocado allí. No hay otra forma conocida ya que los programas no pueden provocar errores por sí mismos. Las buenas prácticas tienen como objetivo prevenir la inserción de errores y, cuando eso falla, eliminarlos antes de la realización de las pruebas o cualquier otra ejecución del programa”.

No es que Mills no crea en el testing, sino que considera que hay errores perfectamente evitables antes de esa fase. Adquirir unas buenas prácticas y unos buenos hábitos en la programación (como por ejemplo probar bien lo que se codifica) ahorra esfuerzo, ya que aplazarlo no solo no lo evita sino que en ocasiones lo multiplica, además de incrementarse el riesgo de que algunos de ellos, que pueden ser críticos, lleguen a producción.

Si estamos abocados a un Death March Project o a un proyecto con unas deficientes condiciones para su desarrollo con unos niveles de calidad mínimos (que viene a ser más o menos lo mismo), cobra especial importancia las personas que participan en el proyecto.

Todas las personas no valen para participar en proyectos de estas características. Son complicados, hay desgaste, requieren mucho esfuerzo, una gran capacidad de trabajo en equipo y determinados perfiles unas importantes habilidades de comunicación y negociación (siempre se está negociando) con el cliente. A esta dificultad hay que añadir el hecho de que no se puede cargar con este tipo de proyectos a las mismas personas porque de lo contrario terminarán desmotivadas, enfermas o fuera de la empresa.

Al final todo conduce a lo mismo. Lo más importante en el desarrollo de software son las personas. Esta es la base de las metodologías ágiles y no se equivocan.

Si las personas que participan en el proyecto son las más adecuadas para el mismo (cosa que es complicado de conseguir por la propia dinámica de funcionamiento de las empresas de desarrollo de software) y además, se les motiva suficientemente (con realidades, no con palmaditas en la espalda) y si la situación de base en el proyecto ofrece alguna esperanza, tal vez pueda haber luz al final del tunel.

Por otro lado, la metodología de desarrollo se tiene que adaptar necesariamente a las circunstancias, hay que prescindir de todo lo que no sea estrictamente necesario para el desarrollo del proyecto. Si las circunstancias son difíciles no nos pongamos obstáculos a nosotros mismos.