Cuando no eres capaz de darte cuenta donde está el error

Julián Gómez Bejarano, Chief Digital Officer LEDAmc nos habla de la relación entre los bombardeos de la Segunda Guerra Mundial y los costes del software, y varios medios se han hecho eco de la noticia:

¿Qué tienen que ver los bombardeos de la Segunda Guerra Mundial con el coste del desarrollo de software?

Abraham Wald nació en una zona de la actual Rumanía en 1902 y nació con una mente privilegiada para las matemáticas. Se doctoró en esta materia justo antes de que los nazis desencadenaran la segunda guerra mundial, pero hete aquí que Abraham Wald era judío y tuvo que abandonar su hogar para sobrevivir.

Pero irse de su hogar no significó abandonar la guerra. Voló a Estados Unidos y desde allí como miembro del America’s Statistical Research Group (SRG) demostró su valía pese a los impedimentos que encontraba, lo trataban como un inmigrante potencialmente hostil.

Esto no le imposibilitó para contribuir de una de las formas más impactantes de las que se dieron en la segunda guerra mundial: mirando donde nadie parecía ver.

Cuentan que un grupo de expertos, incluyendo al propio Wald, fue configurado para tratar de mejorar la resistencia de los bombarderos pesados B-29 aliados que regresaban de las misiones sobre territorio enemigo. Al modo de pre-big data se tomaban anotaciones de cada impacto que presentaban los aviones que retornaban y con ellos se iban pintando en un modelo con la silueta del avión un mapa de calor (heat-map).

Este heat-map mostraba como el fuselaje del avión recibía el doble de impactos que los motores, pero además que las alas recibían mayor número de impactos que el fuselaje e incluso el sistema de combustible recibía más impactos que los motores.

Para los expertos parecía clara la respuesta a la pregunta ¿qué partes del avión habría que reforzar? Todos señalaron el fuselaje y las alas como las partes que había que reforzar. Bueno, todos excepto Abraham Wald que les dio una respuesta que dejó a todos atónitos.

Wald dijo que el refuerzo en el avión debería realizarse en las partes del mismo donde no había impactos de balas o donde había menos debido a que cuando el avión recibía muchos impactos en esas partes no volvía para contarlo. El bajo nivel de impacto en los motores indicaba que cuando los aviones recibían demasiados explotaban y el avión no volvía para contarlo, luego la solución pasaba por protegerlos.

Los datos eran los mismos, pero no supieron ver la solución.

Hace poco nos llamó un cliente del sector de la banca por un motivo similar al de los bombarderos de la segunda guerra mundial, solo que se trataba de desarrollo de software.

Tenían un proceso de desarrollo de software del que estaban muy orgullosos, pero no terminaban de entrar en el time-to-market y querían comprobar que parte tenían que mejorar.

Realizamos un benchmarking de productividad de desarrollo de software y pudimos comprobar que la sensación que tenían se confirmaba para dos tecnologías de las tres tecnologías auditadas: el coste del desarrollo de software estaba por debajo del coste del mercado. Eran mejores, entonces ¿qué estaba pasando?

Para seguir avanzando en el misterio, realizamos un benchmarking de pruebas y aquí encontramos lo que nadie era capaz de vez: el número de casos de prueba que se estaban ejecutando en las pruebas de integración era 5 veces menor a los casos de prueba ejecutados por la media del mercado.

Este hecho estaba generando que el número de errores detectados en las UAT se dispara y, por tanto, retrasando el time-to-market pese a que todo el mundo estaba contento con la parte de desarrollo.

Muchas veces necesitamos contar con nuestro propio Abraham Wald para que mire allá donde nosotros no somos capaces de ver, allá donde a nosotros nunca se nos ocurriría mirar.

Pedir ayuda es de gente inteligente, perseverar en el error no.

Julián Gómez Bejarano, Chief Digital Officer LEDAmc